Microformats Wiki - User contributions [en]

hrecipe-issues

2009-02-15T12:00:06Z

Yde: /* resolved issues */ typo

== issues ==
Please add new issues to the '''bottom''' of this section by copy and pasting the [[hrecipe-issues#template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

== resolved issues ==
<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''author is re-used from hAtom not hCard'''. minor issue. the "author" property is actually re-used from [[hAtom]] rather than hCard - hCard has no such property.
*#* Yikes! Corrected... [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}}2008-01-17 raised by [[User:Yde|Yde]]
<div class="description">
* '''method'''. Would it make sense to [[reuse]] [[hreview|hReview's]] "description" instead of hRecipe's "method" or is this stretching the semantics too far?
** I just discovered that hCalender uses "method", and with totally different semantics. So I guess we MUST change it. I'm not very happy with "description" though - that's a very unspecific term. Maybe "instructions", or "steps", or "preparation" , or "procedure"? They are all 'available'. I like "instructions" most, but since I'm not a native speaker I'm hesitant. Maybe the semantics are too different? Maybe "preparation" is better since we already almost have it (or had it - see the discussion about "preparation-time" -> "duration" above)? [[User:ThomasLoertsch|TomLurge]] 12:24, 21 January 2009 (UTC)
** Since no further comments surfaced I'll change the property name to "instructions". I think it's a fairly unambiguous name which also can easily be reused in other formats. [[User:ThomasLoertsch|TomLurge]] 14:30, 2 Febuary 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''Unnecessary recipe prefixing of summary property.''' Note: this is a re-opening of an issue from [[recipe-issues]]. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
#* proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
#* I agree principally but there are different "summary"s around: The [[hReview]]-Draft specifies a summary as "This optional field serves as a title for the review itself" while the [[hCalendar]] Draft refers to RFC 2445 which defines summary as "This property defines a short summary or subject for the calendar component". I certainly agree more with the semantics from RFC 2445 but referring to either of the two doesn't make much sense right now. Since you are editor of both hReview and hCalendar maybe you can clarify the subject? If hReview would be aligned with RFC 2445 then I would promote dropping the prefix.[[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
#** Agreed, the definitions of "summary" across hCalendar and hReview could be better converged. Please add this as an issue to both [[hcalendar-issues]] and [[hreview-issues]] and I'll follow-up there accordingly. Given that is the path forward, let's fix this immediately in hRecipe now that the issue (and resolution) has been captured. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Will change "recipe-summary" to "summary" as defined in hCalender/RFC2445. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''preparation-time could re-use duration instead''' - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from [[hCalendar]] rather than introducing a new property name.
#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Semantically the reuse of "duration" is okay. RFC 2445 permits multiple duration values "if the property permits" so that should be fine too. If the syntactic differences can be worked out the way Tantek suggests above than it's okay with me to re-use "duration". I'm just not sure if it helps usability to overload properties in such a way but that ay be another discussion on it's own. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
#** The observation that preparation-time uses a nested "note" subproperty may actually reveal a problem with that approach itself, that is, perhaps instead of "preparation-time" with "value" and "note" subproperties, it may be better to refactor it as a "preparation" (an act thereof) with "duration" and "note" subproperties. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Removed the sub-property "note" from the v_0.2 draft format since I now agree that it looks a little overengineered. [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} '''issues too long''' 2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
As threatened 2 weeks ago I heavily re-edited this page because discussions had become a little frayed (and heated at soem points). Have a look at the [http://microformats.org/wiki/index.php?title=hrecipe-issues&oldid=37788 previous version] for the full debate and feel free to re-edit this page if you find that I axed it too much. [[User:ThomasLoertsch|TomLurge]] 14:47, 2 February 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
* '''"num" and "unit"'''. I only recently discovered the properties "type" and "value" from 'hCard'. I'll replace "num" and "unit" from the unfinished 'measure' with them.
** The decision to replace "num", "unit", and "item" with "type" and "value" needs further explanation. Was it due to the fact that measure is unfinished? If so I think leaving "ingredient" and "nutrition" as text strings until measure is finished would be a better idea. The transition from "type"/"value" to measure will be difficult at a later point and I believe measure is more appropriate than re-using hCard. [[User:Yde|Yde]] 11:46, 23 January 2009 (UTC)
*** The proposal to replace "num", "unit", and "item" with "type" and "value" has several reasons: first, i only recently thoroughly and systematically investgated other formats and that's when i found "type" and "value". They have a semantic advantage in that they may be more suitable for cases like value:"2"/type:"eggs" or value:"1/2"/type:"spoonfull" which are rather informal ways of putting measures, at least do not lend themselves easily to formal specification. Another reason is that these terms come from a comparably very stable vocabulary, while measure has not even draft status. It would be perfectly okay for measure to change attribute names, semantics or even the whole structure of the vocabulary. Although it doesn't look like that measure will (have to) do that I'd prefer to stay on the safe side, especially since we might even gain semantic advantage. [[User:ThomasLoertsch|TomLurge]] 19:43, 23 January 2009 (UTC)
**** I'm still not sure this is the right decision. 1) I don't think the semantic meaning of hCard's "type"/"value" is exactly equivalent to measure's "num"/"unit"/"item". From the [[hcard-profile]]: "Value: This class name is used to distinguish the actual *value* of a property from any other cruft that may be in the element representing the property." So what is the actual value of an ingredient? Is it the name of the ingredient or is the quantity? 2) This is ''exactly'' what [[measure]] is for. The advantage of being able to convert measures would IMO be one of the gratest advantages of hRecipe. I don't see why value:"2"/type:"eggs" is better than num:"2"/item:"eggs"? I agree that cases like value:"1/2"/type:"spoonfull" is problematic, but that's a [[measure]] issue. 3) Many [[recipe-formats]] use quantity/unit/item.
***** Proposed resolution: keep "ingredient" as a text string like "yield" - which would also benefit from a measure format - until such a format is ready. [[User:Yde|Yde]] 10:23, 15 February 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} '''new draft'''2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
* The following is a proposal for draft 0.2, reflecting the issues discussed so far. "recipe-title" is replaced with "fn" from hCard (although I'm not convinced that this is a good idea), "recipe-summary" with "summary", "num" and "unit" from the unfinished 'measure' with "type" and "value" from 'hCard' (i only recently discovered them...), "method" (wihch is already used by [[hCalendar]] with "instructions", "preparation-time" with "duration". Two "note"s are deleted for brevity. "summary", "nutrition", "author", "published" and "photo" are marked as 'experimental', meaning that they may be removed from future drafts or the final specification, depending on experience and feedback from implementations :
</div>

=== '''hrecipe'''. Proposal for Draft 0.2 ===

* '''fn'''. the name of the recipe. required. text. re-used from [[hCard]]
* '''ingredient''' required. 1 or more. text with optional valid (x)HTML markup.
** '''value''' and '''type'''. optional. re-used from [[hCard]].
* '''yield'''. optional. text.
* '''instructions'''. optional. text with optional valid (x)HTML markup.
* '''duration'''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
* '''''summary'''''. optional. text. re-used from [[hCalendar]]. [ ''experimental'' ]
* '''''nutrition'''''. optional. 1 or more. [ ''experimental'' ].
** '''''value''''' and '''''type'''''. optional. re-used from [[hCard]]. [ ''experimental'' ].
* '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]]. [ ''experimental'' ].
* '''''published'''''. optional. re-used from [[hAtom]]. [ ''experimental'' ].
* '''''photo'''''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [ ''experimental'' ].
* '''''tag'''''. optional. 1 or more. [ ''experimental'' ].
--[[User:ThomasLoertsch|ThomasLoertsch]] 11:01, 10 February 2009 (UTC)
</div>

== closed issues ==

<div class="vevent">
* {{ClosedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''Too many properties.''' From reviewing the [[recipe-examples]], it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
#* It is not necessarily helpful to constrain a vocabulary by all means. hCard and hCalender are examples for too large vocabularies (which mostly stems from the approach taken of converting an existing vocab 1:1) which are not as easily usable as one would wish. But to be useful a vocabluary should encompass 80:20 of the usecases, otherwise it may well not be worth the burden of implementation. We better try to hit that sweet spot right from the start - since otherwise, how should hRecipe get traction in the wild. All of the proposed properties are used on big recipe sites (many 'user generated content' sites among them) on the web. Please provide more arguments which properties you specifically think are superfluous. The only concrete example you give is to replace title by summary (which I think is a bad idea). [[User:ThomasLoertsch|TomLurge]]
#* The following properties IMO are useful but surely not essential for recipes:
#** "nutrition" - but probably a very welcome addition to a lot of people. Could maybe become a microformat on it's own?
#** "summary" - but people seem to love to associate recipes with little stories and/or need a place to add additional 'unstructured' information.
#** "photo" - but probably a welcome addition in most cases.
#** "published" - but seems like a non brainer either.
#** "author" - although popular on community sites.
#** "tag" - but like "author" very popular with community sites, and useful for finding recipes.
#* My suggestion would be to mark these properties as experimental and follow closely if implementations actually use them. All those properties may be removed later on with not too much strong feelings while the others are considered already quite stable. [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ClosedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]] in the context of issue '''Too many properties'''
<div class="description discussion issues">
# '''Drop "recipe-title".''' In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by [[hCalendar]] (which got it from [[RFC2445]]), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
#* I tend to agree. There are definitely use cases for both "recipe-title/title/fn" and "recipe-summary/summary" - e.g. "[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ A Moroccan-ish Casserole]" sounds more like a summary while "[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti primavera]" is the full name or the title of the recipe. But the problem is, they would serve the same purpose. [[User:Yde|Yde]] 10:07, 17 January 2009 (UTC)
#** Title and summary are different things and they are used differently in the real world. The examples you give are both names/titles/labels/headings, although more or less descriptive. They are short, memorable and make the thing adressable by humans. A summary can be (and mostly is) much longer and serves a different purpose: it describes essential properties of the object at hand, eg: "this is easy and fast to prepare, but still looks impressive", "easy, tasty, fast, vegan, good on cold days" or "the kids loved this last summer, but the ingredients can be hard to get" or "whenever i cook this i start to dream of ..." [[User:ThomasLoertsch|TomLurge]] 14:25, 20 January 2009 (UTC)
#*** Right, on second thought, I believe "title/name" and "summary" are different things. [[User:Yde|Yde]] 11:22, 23 January 2009 (UTC)
#* The term "title" has been so horribly overloaded across formats, vocabularies that it is nearly meaningless and for that reason should be avoided in any/all format efforts, preferring instead something more semantically specific such as "fn" (meaning full/formatted name of an item) or "summary" (when items are labeled more often with a short description/explanation rather than a name). [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#** Synonyms and homonyms are part of the real world - we have to cope with them. Also the word "title" is not horribly overloaded, you're exaggerating here. It just happened that hCard were the first to use it, and in a way that's empirically much less important then the use of "title" as the heading of a resource. Still the real problem is that Microformats have only one namespace and no resolution mechanism for conflicts like this, beside "first come first served". [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
#** Maybe it would be better to make a clear cut with some of the sins of the past and deprecate some terms in hCard / hCalendar[[User:ThomasLoertsch|TomLurge]] 15:30, 3 February 2009 (UTC)
#* "fn" is [[existing-classes|defined]] as "the name of the object" which is pretty much what "recipe-title" means right now. So, whether we chose to keep this property, summary, or both, renaming "recipe-title" to "fn" would make sense. [[User:Yde|Yde]] 23:03, 16 January 2009 (UTC)
#** the definition of "fn" in [[existing-classes|existing classes]] is maybe a little too short. "fn" is defined in hCard which is a reformulation of RFC 2462, which says: "Type name:FN - Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents. -Type special notes: This type is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object. - Type example: 'FN:Mr. John Q. Public\, Esq.'" (http://www.ietf.org/rfc/rfc2426.txt, on page 8). That clearly means a name of a person or an institution. Institution equals a juristical person, so "fn" semantically boils down to 'name of a person'. I wouldn't use that for every object. [[User:ThomasLoertsch|TomLurge]] 14:03, 20 January 2009 (UTC)
#*** Thanks for the clarification. "fn" is definitely not a good idea. [[User:Yde|Yde]] 10:00, 23 January 2009 (UTC)
#*** <code>fn</code> is already reused more generically in hAudio, hReview and hListing (for items). The definition of use within microformats has already been adapted from the strict vcard interpretation in prior work. --[[User:BenWard|BenWard]] 23:04, 27 January 2009 (UTC)
#**** I see. I can't help but thinking: what a mess... What's the family name of a recipe, audio-recording or list-entry? What's the point of re-using a semantically totally void two-letter-acronym, when it doesn't even fit very well? What's the point of reusing an element when I have to lookup the meaning of it every time anyway? [[User:ThomasLoertsch|TomLurge]] 00:48, 28 January 2009 (UTC)
#***** <code>fn</code> is ''formatted''-name, not ‘family’. ‘Name as presented’, ‘display name’. I agree that <code>fn</code> takes a double glance when you're learning, but it's there and the reuse in other specs is consistent; there's a much stronger author benefit in building on common equivalent-semantic vocabulary than introducing synonyms, which I think will cause more confusion. Better to have a strong spec with common vocabulary than introduce duplication. I'll keep in mind that we should better emphasise the expansion of <code>fn</code> in all specs for benefit of new authors. I can see how ‘family name’ is a muddle too easily made in hCard. --[[User:BenWard|BenWard]] 07:01, 28 January 2009 (UTC)
#****** I was referring to the fact that a name of a natural or juridical person is semantically quite different to the name of an object. Other things like the opacity of the two-letter-code "fn" are indeed problematic too but not my main issue here. That vCard-legacy seems to be lurking around every corner. Why not make a clear cut and deprecate the problematic parts like "title" and "fn"? The approach to rather overload the semantics (and the property-constraints) just to keep element-count low only takes that far. In the end it hinders usability instead of improving it. I think [[reuse]] and [[naming-principles]] don't strike the right balance in that respect. [[User:ThomasLoertsch|TomLurge]] 11:45, 28 January 2009 (UTC)
#* why not define a property "name"?! From my understanding of the english language (I'm not a native speaker) "name" is semantically generic enough to serve as a substitute for "title". Defining it rather broadly as "designation or title or denominator or heading of an item" would make it easily reusable. Plus we would have to explicitely discourage it's use for naming real or juristical persons and point to "fn" instead. [[User:ThomasLoertsch|TomLurge]] 12:21, 21 January 2009 (UTC)
#** Hmmm. I would really like to get feedback on this... Again my argumentation:
#*** <code>title</code> would be the best solution but is already "taken". Depercating some of hCalenders sins would be the best solution but seems out of reach so far.
#*** <code>heading</code> would be a possible solution either but seems more suited for prose
#*** <code>name</code> gets the semantics quite well, especially in the case of recipes which are more a "thing" or abstract conceptualization than a work of literature/science/prose
#*** <code>fn</code> with it's subproperties is geared towards natural and juristical persons, which are quite different from things and concepts. Also semantics of the term "fn" are rather opaque, even misleading, which hinder it's usability.
#** Therefor I'd love "title", could live very well with "name", could live still well with "heading" and would sleep bad (but sleep) with "fn". [[User:ThomasLoertsch|TomLurge]] 16:30, 2 Febuary 2009 (UTC)
#** Okay, since there's no response I bow my head to "fn". But it speaks for itself that it's the only tag that has to be explained in the schema. [[User:ThomasLoertsch|ThomasLoertsch]] 11:15, 10 February 2009 (UTC)
</div>
</div>

===template===
{{issues-format}}

== related pages ==
* [[hRecipe]]
* [[hrecipe-feedback|hRecipe feedback]] for general feedback on hRecipe.
* [[recipe]] microformat effort development
* [[recipe-issues]] past issues raised and resolved during [[recipe-brainstorming]] towards the development of hRecipe.

hrecipe-issues

2009-02-15T10:31:00Z

Yde: /* resolved issues */

== issues ==
Please add new issues to the '''bottom''' of this section by copy and pasting the [[hrecipe-issues#template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

== resolved issues ==
<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''author is re-used from hAtom not hCard'''. minor issue. the "author" property is actually re-used from [[hAtom]] rather than hCard - hCard has no such property.
*#* Yikes! Corrected... [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}}2008-01-17 raised by [[User:Yde|Yde]]
<div class="description">
* '''method'''. Would it make sense to [[reuse]] [[hreview|hReview's]] "description" instead of hRecipe's "method" or is this stretching the semantics too far?
** I just discovered that hCalender uses "method", and with totally different semantics. So I guess we MUST change it. I'm not very happy with "description" though - that's a very unspecific term. Maybe "instructions", or "steps", or "preparation" , or "procedure"? They are all 'available'. I like "instructions" most, but since I'm not a native speaker I'm hesitant. Maybe the semantics are too different? Maybe "preparation" is better since we already almost have it (or had it - see the discussion about "preparation-time" -> "duration" above)? [[User:ThomasLoertsch|TomLurge]] 12:24, 21 January 2009 (UTC)
** Since no further comments surfaced I'll change the property name to "instructions". I think it's a fairly unambiguous name which also can easily be reused in other formats. [[User:ThomasLoertsch|TomLurge]] 14:30, 2 Febuary 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''Unnecessary recipe prefixing of summary property.''' Note: this is a re-opening of an issue from [[recipe-issues]]. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
#* proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
#* I agree principally but there are different "summary"s around: The [[hReview]]-Draft specifies a summary as "This optional field serves as a title for the review itself" while the [[hCalendar]] Draft refers to RFC 2445 which defines summary as "This property defines a short summary or subject for the calendar component". I certainly agree more with the semantics from RFC 2445 but referring to either of the two doesn't make much sense right now. Since you are editor of both hReview and hCalendar maybe you can clarify the subject? If hReview would be aligned with RFC 2445 then I would promote dropping the prefix.[[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
#** Agreed, the definitions of "summary" across hCalendar and hReview could be better converged. Please add this as an issue to both [[hcalendar-issues]] and [[hreview-issues]] and I'll follow-up there accordingly. Given that is the path forward, let's fix this immediately in hRecipe now that the issue (and resolution) has been captured. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Will change "recipe-summary" to "summary" as defined in hCalender/RFC2445. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''preparation-time could re-use duration instead''' - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from [[hCalendar]] rather than introducing a new property name.
#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Semantically the reuse of "duration" is okay. RFC 2445 permits multiple duration values "if the property permits" so that should be fine too. If the syntactic differences can be worked out the way Tantek suggests above than it's okay with me to re-use "duration". I'm just not sure if it helps usability to overload properties in such a way but that ay be another discussion on it's own. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
#** The observation that preparation-time uses a nested "note" subproperty may actually reveal a problem with that approach itself, that is, perhaps instead of "preparation-time" with "value" and "note" subproperties, it may be better to refactor it as a "preparation" (an act thereof) with "duration" and "note" subproperties. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Removed the sub-property "note" from the v_0.2 draft format since I now agree that it looks a little overengineered. [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} '''issues too long''' 2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
As threatened 2 weeks ago I heavily re-edited this page because discussions had become a little frayed (and heated at soem points). Have a look at the [http://microformats.org/wiki/index.php?title=hrecipe-issues&oldid=37788 previous version] for the full debate and feel free to re-edit this page if you find that I axed it too much. [[User:ThomasLoertsch|TomLurge]] 14:47, 2 February 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
* '''"num" and "unit"'''. I only recently discovered the properties "type" and "value" from 'hCard'. I'll replace "num" and "unit" from the unfinished 'measure' with them.
** The decision to replace "num", "unit", and "item" with "type" and "value" needs further explanation. Was it due to the fact that measure is unfinished? If so I think leaving "ingredient" and "nutrition" as text strings until measure is finished would be a better idea. The transition from "type"/"value" to measure will be difficult at a later point and I believe measure is more appropriate than re-using hCard. [[User:Yde|Yde]] 11:46, 23 January 2009 (UTC)
*** The proposal to replace "num", "unit", and "item" with "type" and "value" has several reasons: first, i only recently thoroughly and systematically investgated other formats and that's when i found "type" and "value". They have a semantic advantage in that they may be more suitable for cases like value:"2"/type:"eggs" or value:"1/2"/type:"spoonfull" which are rather informal ways of putting measures, at least do not lend themselves easily to formal specification. Another reason is that these terms come from a comparably very stable vocabulary, while measure has not even draft status. It would be perfectly okay for measure to change attribute names, semantics or even the whole structure of the vocabulary. Although it doesn't look like that measure will (have to) do that I'd prefer to stay on the safe side, especially since we might even gain semantic advantage. [[User:ThomasLoertsch|TomLurge]] 19:43, 23 January 2009 (UTC)
**** I'm still not sure this is the right decision. 1) I don't think the semantic meaning of hCard's "type"/"value" is exactly equivalent to measure's "num"/"unit"/"item". From the [[hcard-profile]]: "Value: This class name is used to distinguish the actual *value* of a property from any other cruft that may be in the element representing the property." So what is the actual value of an ingredient? Is it the name of the ingredient or is the quantity? 2) This is ''exactly'' what [[measure]] is for. The advantage of being able to convert measures would IMO be one of the gratest advantages of hRecipe. I don't see why value:"2"/type:"eggs" is better than num:"2"/item:"eggs"? I agree that cases like value:"1/2"/type:"spoonfull" is problematic, but that's a [[measure]] isue. 3) Many [[recipe-formats]] use quantity/unit/item.
***** Proposed resolution: keep "ingredient" as a text string like "yield" - which would also benefit from a measure format - until such a format is ready. [[User:Yde|Yde]] 10:23, 15 February 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} '''new draft'''2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
* The following is a proposal for draft 0.2, reflecting the issues discussed so far. "recipe-title" is replaced with "fn" from hCard (although I'm not convinced that this is a good idea), "recipe-summary" with "summary", "num" and "unit" from the unfinished 'measure' with "type" and "value" from 'hCard' (i only recently discovered them...), "method" (wihch is already used by [[hCalendar]] with "instructions", "preparation-time" with "duration". Two "note"s are deleted for brevity. "summary", "nutrition", "author", "published" and "photo" are marked as 'experimental', meaning that they may be removed from future drafts or the final specification, depending on experience and feedback from implementations :
</div>

=== '''hrecipe'''. Proposal for Draft 0.2 ===

* '''fn'''. the name of the recipe. required. text. re-used from [[hCard]]
* '''ingredient''' required. 1 or more. text with optional valid (x)HTML markup.
** '''value''' and '''type'''. optional. re-used from [[hCard]].
* '''yield'''. optional. text.
* '''instructions'''. optional. text with optional valid (x)HTML markup.
* '''duration'''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
* '''''summary'''''. optional. text. re-used from [[hCalendar]]. [ ''experimental'' ]
* '''''nutrition'''''. optional. 1 or more. [ ''experimental'' ].
** '''''value''''' and '''''type'''''. optional. re-used from [[hCard]]. [ ''experimental'' ].
* '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]]. [ ''experimental'' ].
* '''''published'''''. optional. re-used from [[hAtom]]. [ ''experimental'' ].
* '''''photo'''''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [ ''experimental'' ].
* '''''tag'''''. optional. 1 or more. [ ''experimental'' ].
--[[User:ThomasLoertsch|ThomasLoertsch]] 11:01, 10 February 2009 (UTC)
</div>

== closed issues ==

<div class="vevent">
* {{ClosedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''Too many properties.''' From reviewing the [[recipe-examples]], it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
#* It is not necessarily helpful to constrain a vocabulary by all means. hCard and hCalender are examples for too large vocabularies (which mostly stems from the approach taken of converting an existing vocab 1:1) which are not as easily usable as one would wish. But to be useful a vocabluary should encompass 80:20 of the usecases, otherwise it may well not be worth the burden of implementation. We better try to hit that sweet spot right from the start - since otherwise, how should hRecipe get traction in the wild. All of the proposed properties are used on big recipe sites (many 'user generated content' sites among them) on the web. Please provide more arguments which properties you specifically think are superfluous. The only concrete example you give is to replace title by summary (which I think is a bad idea). [[User:ThomasLoertsch|TomLurge]]
#* The following properties IMO are useful but surely not essential for recipes:
#** "nutrition" - but probably a very welcome addition to a lot of people. Could maybe become a microformat on it's own?
#** "summary" - but people seem to love to associate recipes with little stories and/or need a place to add additional 'unstructured' information.
#** "photo" - but probably a welcome addition in most cases.
#** "published" - but seems like a non brainer either.
#** "author" - although popular on community sites.
#** "tag" - but like "author" very popular with community sites, and useful for finding recipes.
#* My suggestion would be to mark these properties as experimental and follow closely if implementations actually use them. All those properties may be removed later on with not too much strong feelings while the others are considered already quite stable. [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ClosedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]] in the context of issue '''Too many properties'''
<div class="description discussion issues">
# '''Drop "recipe-title".''' In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by [[hCalendar]] (which got it from [[RFC2445]]), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
#* I tend to agree. There are definitely use cases for both "recipe-title/title/fn" and "recipe-summary/summary" - e.g. "[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ A Moroccan-ish Casserole]" sounds more like a summary while "[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti primavera]" is the full name or the title of the recipe. But the problem is, they would serve the same purpose. [[User:Yde|Yde]] 10:07, 17 January 2009 (UTC)
#** Title and summary are different things and they are used differently in the real world. The examples you give are both names/titles/labels/headings, although more or less descriptive. They are short, memorable and make the thing adressable by humans. A summary can be (and mostly is) much longer and serves a different purpose: it describes essential properties of the object at hand, eg: "this is easy and fast to prepare, but still looks impressive", "easy, tasty, fast, vegan, good on cold days" or "the kids loved this last summer, but the ingredients can be hard to get" or "whenever i cook this i start to dream of ..." [[User:ThomasLoertsch|TomLurge]] 14:25, 20 January 2009 (UTC)
#*** Right, on second thought, I believe "title/name" and "summary" are different things. [[User:Yde|Yde]] 11:22, 23 January 2009 (UTC)
#* The term "title" has been so horribly overloaded across formats, vocabularies that it is nearly meaningless and for that reason should be avoided in any/all format efforts, preferring instead something more semantically specific such as "fn" (meaning full/formatted name of an item) or "summary" (when items are labeled more often with a short description/explanation rather than a name). [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#** Synonyms and homonyms are part of the real world - we have to cope with them. Also the word "title" is not horribly overloaded, you're exaggerating here. It just happened that hCard were the first to use it, and in a way that's empirically much less important then the use of "title" as the heading of a resource. Still the real problem is that Microformats have only one namespace and no resolution mechanism for conflicts like this, beside "first come first served". [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
#** Maybe it would be better to make a clear cut with some of the sins of the past and deprecate some terms in hCard / hCalendar[[User:ThomasLoertsch|TomLurge]] 15:30, 3 February 2009 (UTC)
#* "fn" is [[existing-classes|defined]] as "the name of the object" which is pretty much what "recipe-title" means right now. So, whether we chose to keep this property, summary, or both, renaming "recipe-title" to "fn" would make sense. [[User:Yde|Yde]] 23:03, 16 January 2009 (UTC)
#** the definition of "fn" in [[existing-classes|existing classes]] is maybe a little too short. "fn" is defined in hCard which is a reformulation of RFC 2462, which says: "Type name:FN - Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents. -Type special notes: This type is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object. - Type example: 'FN:Mr. John Q. Public\, Esq.'" (http://www.ietf.org/rfc/rfc2426.txt, on page 8). That clearly means a name of a person or an institution. Institution equals a juristical person, so "fn" semantically boils down to 'name of a person'. I wouldn't use that for every object. [[User:ThomasLoertsch|TomLurge]] 14:03, 20 January 2009 (UTC)
#*** Thanks for the clarification. "fn" is definitely not a good idea. [[User:Yde|Yde]] 10:00, 23 January 2009 (UTC)
#*** <code>fn</code> is already reused more generically in hAudio, hReview and hListing (for items). The definition of use within microformats has already been adapted from the strict vcard interpretation in prior work. --[[User:BenWard|BenWard]] 23:04, 27 January 2009 (UTC)
#**** I see. I can't help but thinking: what a mess... What's the family name of a recipe, audio-recording or list-entry? What's the point of re-using a semantically totally void two-letter-acronym, when it doesn't even fit very well? What's the point of reusing an element when I have to lookup the meaning of it every time anyway? [[User:ThomasLoertsch|TomLurge]] 00:48, 28 January 2009 (UTC)
#***** <code>fn</code> is ''formatted''-name, not ‘family’. ‘Name as presented’, ‘display name’. I agree that <code>fn</code> takes a double glance when you're learning, but it's there and the reuse in other specs is consistent; there's a much stronger author benefit in building on common equivalent-semantic vocabulary than introducing synonyms, which I think will cause more confusion. Better to have a strong spec with common vocabulary than introduce duplication. I'll keep in mind that we should better emphasise the expansion of <code>fn</code> in all specs for benefit of new authors. I can see how ‘family name’ is a muddle too easily made in hCard. --[[User:BenWard|BenWard]] 07:01, 28 January 2009 (UTC)
#****** I was referring to the fact that a name of a natural or juridical person is semantically quite different to the name of an object. Other things like the opacity of the two-letter-code "fn" are indeed problematic too but not my main issue here. That vCard-legacy seems to be lurking around every corner. Why not make a clear cut and deprecate the problematic parts like "title" and "fn"? The approach to rather overload the semantics (and the property-constraints) just to keep element-count low only takes that far. In the end it hinders usability instead of improving it. I think [[reuse]] and [[naming-principles]] don't strike the right balance in that respect. [[User:ThomasLoertsch|TomLurge]] 11:45, 28 January 2009 (UTC)
#* why not define a property "name"?! From my understanding of the english language (I'm not a native speaker) "name" is semantically generic enough to serve as a substitute for "title". Defining it rather broadly as "designation or title or denominator or heading of an item" would make it easily reusable. Plus we would have to explicitely discourage it's use for naming real or juristical persons and point to "fn" instead. [[User:ThomasLoertsch|TomLurge]] 12:21, 21 January 2009 (UTC)
#** Hmmm. I would really like to get feedback on this... Again my argumentation:
#*** <code>title</code> would be the best solution but is already "taken". Depercating some of hCalenders sins would be the best solution but seems out of reach so far.
#*** <code>heading</code> would be a possible solution either but seems more suited for prose
#*** <code>name</code> gets the semantics quite well, especially in the case of recipes which are more a "thing" or abstract conceptualization than a work of literature/science/prose
#*** <code>fn</code> with it's subproperties is geared towards natural and juristical persons, which are quite different from things and concepts. Also semantics of the term "fn" are rather opaque, even misleading, which hinder it's usability.
#** Therefor I'd love "title", could live very well with "name", could live still well with "heading" and would sleep bad (but sleep) with "fn". [[User:ThomasLoertsch|TomLurge]] 16:30, 2 Febuary 2009 (UTC)
#** Okay, since there's no response I bow my head to "fn". But it speaks for itself that it's the only tag that has to be explained in the schema. [[User:ThomasLoertsch|ThomasLoertsch]] 11:15, 10 February 2009 (UTC)
</div>
</div>

===template===
{{issues-format}}

== related pages ==
* [[hRecipe]]
* [[hrecipe-feedback|hRecipe feedback]] for general feedback on hRecipe.
* [[recipe]] microformat effort development
* [[recipe-issues]] past issues raised and resolved during [[recipe-brainstorming]] towards the development of hRecipe.

hrecipe-issues

2009-02-15T10:23:19Z

Yde: /* resolved issues */ Further discussion about "num" and "unit"

== issues ==
Please add new issues to the '''bottom''' of this section by copy and pasting the [[hrecipe-issues#template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

== resolved issues ==
<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''author is re-used from hAtom not hCard'''. minor issue. the "author" property is actually re-used from [[hAtom]] rather than hCard - hCard has no such property.
*#* Yikes! Corrected... [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}}2008-01-17 raised by [[User:Yde|Yde]]
<div class="description">
* '''method'''. Would it make sense to [[reuse]] [[hreview|hReview's]] "description" instead of hRecipe's "method" or is this stretching the semantics too far?
** I just discovered that hCalender uses "method", and with totally different semantics. So I guess we MUST change it. I'm not very happy with "description" though - that's a very unspecific term. Maybe "instructions", or "steps", or "preparation" , or "procedure"? They are all 'available'. I like "instructions" most, but since I'm not a native speaker I'm hesitant. Maybe the semantics are too different? Maybe "preparation" is better since we already almost have it (or had it - see the discussion about "preparation-time" -> "duration" above)? [[User:ThomasLoertsch|TomLurge]] 12:24, 21 January 2009 (UTC)
** Since no further comments surfaced I'll change the property name to "instructions". I think it's a fairly unambiguous name which also can easily be reused in other formats. [[User:ThomasLoertsch|TomLurge]] 14:30, 2 Febuary 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''Unnecessary recipe prefixing of summary property.''' Note: this is a re-opening of an issue from [[recipe-issues]]. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
#* proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
#* I agree principally but there are different "summary"s around: The [[hReview]]-Draft specifies a summary as "This optional field serves as a title for the review itself" while the [[hCalendar]] Draft refers to RFC 2445 which defines summary as "This property defines a short summary or subject for the calendar component". I certainly agree more with the semantics from RFC 2445 but referring to either of the two doesn't make much sense right now. Since you are editor of both hReview and hCalendar maybe you can clarify the subject? If hReview would be aligned with RFC 2445 then I would promote dropping the prefix.[[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
#** Agreed, the definitions of "summary" across hCalendar and hReview could be better converged. Please add this as an issue to both [[hcalendar-issues]] and [[hreview-issues]] and I'll follow-up there accordingly. Given that is the path forward, let's fix this immediately in hRecipe now that the issue (and resolution) has been captured. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Will change "recipe-summary" to "summary" as defined in hCalender/RFC2445. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''preparation-time could re-use duration instead''' - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from [[hCalendar]] rather than introducing a new property name.
#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Semantically the reuse of "duration" is okay. RFC 2445 permits multiple duration values "if the property permits" so that should be fine too. If the syntactic differences can be worked out the way Tantek suggests above than it's okay with me to re-use "duration". I'm just not sure if it helps usability to overload properties in such a way but that ay be another discussion on it's own. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
#** The observation that preparation-time uses a nested "note" subproperty may actually reveal a problem with that approach itself, that is, perhaps instead of "preparation-time" with "value" and "note" subproperties, it may be better to refactor it as a "preparation" (an act thereof) with "duration" and "note" subproperties. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Removed the sub-property "note" from the v_0.2 draft format since I now agree that it looks a little overengineered. [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} '''issues too long''' 2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
As threatened 2 weeks ago I heavily re-edited this page because discussions had become a little frayed (and heated at soem points). Have a look at the [http://microformats.org/wiki/index.php?title=hrecipe-issues&oldid=37788 previous version] for the full debate and feel free to re-edit this page if you find that I axed it too much. [[User:ThomasLoertsch|TomLurge]] 14:47, 2 February 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} 2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
* '''"num" and "unit"'''. I only recently discovered the properties "type" and "value" from 'hCard'. I'll replace "num" and "unit" from the unfinished 'measure' with them.
** The decision to replace "num", "unit", and "item" with "type" and "value" needs further explanation. Was it due to the fact that measure is unfinished? If so I think leaving "ingredient" and "nutrition" as text strings until measure is finished would be a better idea. The transition from "type"/"value" to measure will be difficult at a later point and I believe measure is more appropriate than re-using hCard. [[User:Yde|Yde]] 11:46, 23 January 2009 (UTC)
*** The proposal to replace "num", "unit", and "item" with "type" and "value" has several reasons: first, i only recently thoroughly and systematically investgated other formats and that's when i found "type" and "value". They have a semantic advantage in that they may be more suitable for cases like value:"2"/type:"eggs" or value:"1/2"/type:"spoonfull" which are rather informal ways of putting measures, at least do not lend themselves easily to formal specification. Another reason is that these terms come from a comparably very stable vocabulary, while measure has not even draft status. It would be perfectly okay for measure to change attribute names, semantics or even the whole structure of the vocabulary. Although it doesn't look like that measure will (have to) do that I'd prefer to stay on the safe side, especially since we might even gain semantic advantage. [[User:ThomasLoertsch|TomLurge]] 19:43, 23 January 2009 (UTC)
**** I'm still not sure this is the right decision. 1) I don't think the semantic meaning of hCard's "type"/"value" is exactly equivalent to measure's "num"/"unit"/"item". From the [[hcard-profile]]: "Value: This class name is used to distinguish the actual *value* of a property from any other cruft that may be in the element representing the property." So what is the actual value of an ingredient? Is it the name of the ingredient or is the quantity? 2) This is ''exactly'' what [[measure]] is for. The advantage of being able to convert measures would IMO be one of the gratest advantages of hRecipe. I don't see why value:"2"/type:"eggs" is better than num:"2"/item:"eggs"? I agree that cases like value:"1/2"/type:"spoonfull" is problematic, but that's a [[measure]] isue. 3) Many [[recipe-formats]] use quantity/unit/item.
I think keeping "ingredient" as a text string like "yield" - which would also benefit from a measure format - until a measure format is ready would be a better idea. [[User:Yde|Yde]] 10:23, 15 February 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} '''new draft'''2009-01-22 raised by [[User:ThomasLoertsch|TomLurge]]
<div class="description">
* The following is a proposal for draft 0.2, reflecting the issues discussed so far. "recipe-title" is replaced with "fn" from hCard (although I'm not convinced that this is a good idea), "recipe-summary" with "summary", "num" and "unit" from the unfinished 'measure' with "type" and "value" from 'hCard' (i only recently discovered them...), "method" (wihch is already used by [[hCalendar]] with "instructions", "preparation-time" with "duration". Two "note"s are deleted for brevity. "summary", "nutrition", "author", "published" and "photo" are marked as 'experimental', meaning that they may be removed from future drafts or the final specification, depending on experience and feedback from implementations :
</div>

=== '''hrecipe'''. Proposal for Draft 0.2 ===

* '''fn'''. the name of the recipe. required. text. re-used from [[hCard]]
* '''ingredient''' required. 1 or more. text with optional valid (x)HTML markup.
** '''value''' and '''type'''. optional. re-used from [[hCard]].
* '''yield'''. optional. text.
* '''instructions'''. optional. text with optional valid (x)HTML markup.
* '''duration'''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
* '''''summary'''''. optional. text. re-used from [[hCalendar]]. [ ''experimental'' ]
* '''''nutrition'''''. optional. 1 or more. [ ''experimental'' ].
** '''''value''''' and '''''type'''''. optional. re-used from [[hCard]]. [ ''experimental'' ].
* '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]]. [ ''experimental'' ].
* '''''published'''''. optional. re-used from [[hAtom]]. [ ''experimental'' ].
* '''''photo'''''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [ ''experimental'' ].
* '''''tag'''''. optional. 1 or more. [ ''experimental'' ].
--[[User:ThomasLoertsch|ThomasLoertsch]] 11:01, 10 February 2009 (UTC)
</div>

== closed issues ==

<div class="vevent">
* {{ClosedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description discussion issues">
# '''Too many properties.''' From reviewing the [[recipe-examples]], it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
#* It is not necessarily helpful to constrain a vocabulary by all means. hCard and hCalender are examples for too large vocabularies (which mostly stems from the approach taken of converting an existing vocab 1:1) which are not as easily usable as one would wish. But to be useful a vocabluary should encompass 80:20 of the usecases, otherwise it may well not be worth the burden of implementation. We better try to hit that sweet spot right from the start - since otherwise, how should hRecipe get traction in the wild. All of the proposed properties are used on big recipe sites (many 'user generated content' sites among them) on the web. Please provide more arguments which properties you specifically think are superfluous. The only concrete example you give is to replace title by summary (which I think is a bad idea). [[User:ThomasLoertsch|TomLurge]]
#* The following properties IMO are useful but surely not essential for recipes:
#** "nutrition" - but probably a very welcome addition to a lot of people. Could maybe become a microformat on it's own?
#** "summary" - but people seem to love to associate recipes with little stories and/or need a place to add additional 'unstructured' information.
#** "photo" - but probably a welcome addition in most cases.
#** "published" - but seems like a non brainer either.
#** "author" - although popular on community sites.
#** "tag" - but like "author" very popular with community sites, and useful for finding recipes.
#* My suggestion would be to mark these properties as experimental and follow closely if implementations actually use them. All those properties may be removed later on with not too much strong feelings while the others are considered already quite stable. [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ClosedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]] in the context of issue '''Too many properties'''
<div class="description discussion issues">
# '''Drop "recipe-title".''' In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by [[hCalendar]] (which got it from [[RFC2445]]), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
#* I tend to agree. There are definitely use cases for both "recipe-title/title/fn" and "recipe-summary/summary" - e.g. "[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ A Moroccan-ish Casserole]" sounds more like a summary while "[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti primavera]" is the full name or the title of the recipe. But the problem is, they would serve the same purpose. [[User:Yde|Yde]] 10:07, 17 January 2009 (UTC)
#** Title and summary are different things and they are used differently in the real world. The examples you give are both names/titles/labels/headings, although more or less descriptive. They are short, memorable and make the thing adressable by humans. A summary can be (and mostly is) much longer and serves a different purpose: it describes essential properties of the object at hand, eg: "this is easy and fast to prepare, but still looks impressive", "easy, tasty, fast, vegan, good on cold days" or "the kids loved this last summer, but the ingredients can be hard to get" or "whenever i cook this i start to dream of ..." [[User:ThomasLoertsch|TomLurge]] 14:25, 20 January 2009 (UTC)
#*** Right, on second thought, I believe "title/name" and "summary" are different things. [[User:Yde|Yde]] 11:22, 23 January 2009 (UTC)
#* The term "title" has been so horribly overloaded across formats, vocabularies that it is nearly meaningless and for that reason should be avoided in any/all format efforts, preferring instead something more semantically specific such as "fn" (meaning full/formatted name of an item) or "summary" (when items are labeled more often with a short description/explanation rather than a name). [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#** Synonyms and homonyms are part of the real world - we have to cope with them. Also the word "title" is not horribly overloaded, you're exaggerating here. It just happened that hCard were the first to use it, and in a way that's empirically much less important then the use of "title" as the heading of a resource. Still the real problem is that Microformats have only one namespace and no resolution mechanism for conflicts like this, beside "first come first served". [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
#** Maybe it would be better to make a clear cut with some of the sins of the past and deprecate some terms in hCard / hCalendar[[User:ThomasLoertsch|TomLurge]] 15:30, 3 February 2009 (UTC)
#* "fn" is [[existing-classes|defined]] as "the name of the object" which is pretty much what "recipe-title" means right now. So, whether we chose to keep this property, summary, or both, renaming "recipe-title" to "fn" would make sense. [[User:Yde|Yde]] 23:03, 16 January 2009 (UTC)
#** the definition of "fn" in [[existing-classes|existing classes]] is maybe a little too short. "fn" is defined in hCard which is a reformulation of RFC 2462, which says: "Type name:FN - Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents. -Type special notes: This type is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object. - Type example: 'FN:Mr. John Q. Public\, Esq.'" (http://www.ietf.org/rfc/rfc2426.txt, on page 8). That clearly means a name of a person or an institution. Institution equals a juristical person, so "fn" semantically boils down to 'name of a person'. I wouldn't use that for every object. [[User:ThomasLoertsch|TomLurge]] 14:03, 20 January 2009 (UTC)
#*** Thanks for the clarification. "fn" is definitely not a good idea. [[User:Yde|Yde]] 10:00, 23 January 2009 (UTC)
#*** <code>fn</code> is already reused more generically in hAudio, hReview and hListing (for items). The definition of use within microformats has already been adapted from the strict vcard interpretation in prior work. --[[User:BenWard|BenWard]] 23:04, 27 January 2009 (UTC)
#**** I see. I can't help but thinking: what a mess... What's the family name of a recipe, audio-recording or list-entry? What's the point of re-using a semantically totally void two-letter-acronym, when it doesn't even fit very well? What's the point of reusing an element when I have to lookup the meaning of it every time anyway? [[User:ThomasLoertsch|TomLurge]] 00:48, 28 January 2009 (UTC)
#***** <code>fn</code> is ''formatted''-name, not ‘family’. ‘Name as presented’, ‘display name’. I agree that <code>fn</code> takes a double glance when you're learning, but it's there and the reuse in other specs is consistent; there's a much stronger author benefit in building on common equivalent-semantic vocabulary than introducing synonyms, which I think will cause more confusion. Better to have a strong spec with common vocabulary than introduce duplication. I'll keep in mind that we should better emphasise the expansion of <code>fn</code> in all specs for benefit of new authors. I can see how ‘family name’ is a muddle too easily made in hCard. --[[User:BenWard|BenWard]] 07:01, 28 January 2009 (UTC)
#****** I was referring to the fact that a name of a natural or juridical person is semantically quite different to the name of an object. Other things like the opacity of the two-letter-code "fn" are indeed problematic too but not my main issue here. That vCard-legacy seems to be lurking around every corner. Why not make a clear cut and deprecate the problematic parts like "title" and "fn"? The approach to rather overload the semantics (and the property-constraints) just to keep element-count low only takes that far. In the end it hinders usability instead of improving it. I think [[reuse]] and [[naming-principles]] don't strike the right balance in that respect. [[User:ThomasLoertsch|TomLurge]] 11:45, 28 January 2009 (UTC)
#* why not define a property "name"?! From my understanding of the english language (I'm not a native speaker) "name" is semantically generic enough to serve as a substitute for "title". Defining it rather broadly as "designation or title or denominator or heading of an item" would make it easily reusable. Plus we would have to explicitely discourage it's use for naming real or juristical persons and point to "fn" instead. [[User:ThomasLoertsch|TomLurge]] 12:21, 21 January 2009 (UTC)
#** Hmmm. I would really like to get feedback on this... Again my argumentation:
#*** <code>title</code> would be the best solution but is already "taken". Depercating some of hCalenders sins would be the best solution but seems out of reach so far.
#*** <code>heading</code> would be a possible solution either but seems more suited for prose
#*** <code>name</code> gets the semantics quite well, especially in the case of recipes which are more a "thing" or abstract conceptualization than a work of literature/science/prose
#*** <code>fn</code> with it's subproperties is geared towards natural and juristical persons, which are quite different from things and concepts. Also semantics of the term "fn" are rather opaque, even misleading, which hinder it's usability.
#** Therefor I'd love "title", could live very well with "name", could live still well with "heading" and would sleep bad (but sleep) with "fn". [[User:ThomasLoertsch|TomLurge]] 16:30, 2 Febuary 2009 (UTC)
#** Okay, since there's no response I bow my head to "fn". But it speaks for itself that it's the only tag that has to be explained in the schema. [[User:ThomasLoertsch|ThomasLoertsch]] 11:15, 10 February 2009 (UTC)
</div>
</div>

===template===
{{issues-format}}

== related pages ==
* [[hRecipe]]
* [[hrecipe-feedback|hRecipe feedback]] for general feedback on hRecipe.
* [[recipe]] microformat effort development
* [[recipe-issues]] past issues raised and resolved during [[recipe-brainstorming]] towards the development of hRecipe.

hrecipe-issues

2009-01-23T11:48:32Z

Yde: /* issues */

<entry-title>hRecipe issues</entry-title>

This page reflects issues raised about the [[hRecipe]] microformat.

Past issues captured during brainstorming towards hRecipe can be found in [[recipe-issues]].

Some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Please read this page (and [[recipe-issues]]) carefully ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

If you have general feedback on hRecipe (positive/neutral/negative) please add to [[hrecipe-feedback]] rather than this document.

== issues ==
Please add new issues to the '''bottom''' of this section by copy and pasting the [[hrecipe-issues#template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

<div class="vevent">
* {{OpenIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''Too many properties.''' From reviewing the [[recipe-examples]], it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
*#* btw: this is a first draft but a rather well worked out brainstorming proposal has been around for over a year, a refinement of it for another few months and the draft only builds on them. you are chiming in rather late - which is not a problem, but you should consider that a lot of thought already went into this format. [[User:ThomasLoertsch|TomLurge]] 14:05, 20 January 2009 (UTC)
*#* proposed resolution: Drop "recipe-title". In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by [[hCalendar]] (which got it from [[RFC2445]]), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
*#*# I tend to agree. There are definitely use cases for both "recipe-title/title/fn" and "recipe-summary/summary" - e.g. "[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ A Moroccan-ish Casserole]" sounds more like a summary while "[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti primavera]" is the full name or the title of the recipe. But the problem is, they would serve the same purpose. [[User:Yde|Yde]] 10:07, 17 January 2009 (UTC)
*#*#* These really are different things: the examples you give are both names/titles/labels/headings, though more or less descriptive. They are short, memorable and make the thing adressable by humans. A summary can be (and mostly is) much longer and serves a different purpose: it describes essential properties of the object at hand, eg: "this is easy and fast to prepare, but still looks impressive" or "the kids loved this last summer, but the ingredients can be hard to get" or "whenever i cook this i start to dream of ..." - whatever. these are summaries, abstracts, introductions. If "too many properties" are really a problem of hRecipe I could live without this property but I still think it makes sense. [[User:ThomasLoertsch|TomLurge]] 14:25, 20 January 2009 (UTC)
*#*#*# Right, that's actually how I thought of it before this whole "too many properties" issue. So on second thought, I believe "title/name" and "summary" are different things. [[User:Yde|Yde]] 11:22, 23 January 2009 (UTC)
*#* hRecipe certainly is not a very short format, but that stems from the complexity of the topic. Other seemingly simple issues like vCards also have a lot of properties. 'Nutrition' could be a candidate for a microformat on it's own - but then, since it can be reused anyway, why bother? If your issue leads to the proposal that we should keep this in mind and wait for implementations to prove the point then I agree - although of course I think that it's as short as reasonably possible.I disagree with the proposed resolution though - title and summary are different things and they are used differently in the real world. They are wo different elements in Dublin Core and I find no Thesaurus listing them together. Plus I personally am not aware of any recipes that don't have a title. The summary could be dropped but to what advantage since you are right with your next point and summary is already defined elsewhere? The real problem lies in the usage of 'title' in hCard and can't be solved by shoehorning other titles in something else. [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#*# Several problems with the reasoning above. First, assertion of "complexity of the topic" is insufficient. Per [[recipe-examples]] and rough 80% of the semantics implied therein - it is *not* a complex topic. Arguments from such data samples trumps any argument from theoretical complexity as we are going for a rough representation of real world use, not 99+% theoretical representation. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* Maybe "complex" is the wrong wording, but there certainly are a lot of properties to take into account. Anyway I would find it more helpfull if you could provide more insight what properties you specifically think are too much for a first draft. The only concrete example you give is the title, but you give no convincing argument for that. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*# "hCard has lots of properties" is an insufficient justification for breaking any principles as the principles were derived from some of the experience gained (lessons learned) from the development of the early microformats like hCard and hCalendar. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*# The use/assertion of "wait for implementation to prove the point" is assuming the wrong burden of proof. The burden of proof is to demonstrate the need for more complexity not less. That is, with microformats, we prefer starting smaller rather than larger. This is one of the [[principles]]. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*# I'm not taking these arguments lightly, but there are counter arguments too: while hCard and hCalender are extremly large vocabularies (which mostly stems from the approach taken of converting an existing vocab 1:1) it is also not necessarily helpfull to constrain a vocab by all means. when I'm looking for a vocabulary for a certain use I'm not looking for the smallest vocab but for theeon that fits my needs, more or less. if it's much too small I feel taht it's not of much help and I look somewhere else. the 80:20 rule might be a better guide, again. a vocabulary should encompass most of the usecases, and right from the start - since otherwise, why should it start to get adopted. it's right to start prudentious since it's always easier to add properties than to remove them. but don't exegerate, neither with minimization nor with exhaustiveness. for hrecipe i visited a lot of the big sites like recipetsar, which are full of user generated content. they use a lot of properties, certainly more than we do. a very minimal, but perfectly useful set of elements would be "name", "ingredients", "instructions". just those 3. but people upload pictures, socialize by stating their authorship, need to know how long preparation will take, care for nutritional information etc. so these properties are not just superfluous spaghetti vocabulary - they serve real needs, as you can see on those massively popular sites. so where's the sweet spot? 3 properties is extremely small, the 70 or so properties of hCard is extremely big. I think with about 10 properties hRecipe is not very big. you'll certainly not get lost in a soup of properties. and for implementors it's not too hard to go from 3 to 10 properties as long as they are not complexly nested/intertwined/constrained. 10 are certainly more than absolutely necessary - as I said, 3 would be my minimum -, so there's always room for debate and optimization. but please be specific, don't just argue with just "principles" and "lessons learned". [[User:ThomasLoertsch|TomLurge]] 11:08, 22 January 2009 (UTC)
*#*# Reasoning by analogy/justification of Dublin Core is insufficient, because schema should always be based on real world samples of *data* not on other formats. Also, the properties in Dublin Core are notoriously abstract/confusing/overloaded, and thus make a particularly poor base from which to reason from. Similarly reasoning from an abstract thesaurus definition is insufficient, as the thesaurus definition itself is not based on any sampling of real world publication data. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* So you're suggesting that Dublin Core or a Thesaurus are not based on real world data but are made up out of the abstract while only the real world examples gathered on this site are the real deal? Well... I don't see what's so very special about the microformats process that it can singlehandedly negate all the work other people have done. I can add some examples to the examples page, from sites that together make up the vast majority of recipes on the (english speaking) net (both by number and by visits). You'll find all the properties mentioned in the hRecipe format (and you'll certainly find that they all have a title). And I just double-checked the [[recipe-examples]] page: 'all' the recipe examples there have a title and in all but one cases it is called "title" too. It's very helpfull to have some process but almost all your argumentation centers around the process while you provide very little concrete criticism on the properties themselves. [[User:ThomasLoertsch|TomLurge]] 14:08, 20 January 2009 (UTC)
*#*# Reasoning by absence of negative is flawed: "am not aware of any recipes that don't have a title" - absence of a negative cannot be used to prove an assertion to be true, only the possibility of being true. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* Get your logics right: double negation is the opposite of negation. You can easily reformulate my assertion to: "Almost all recipes I'm aware of do have a title". [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*# Finally, the "real" problem is not the use of "title" within hCard but rather that the term "title" has been so horribly overloaded across formats, vocabularies that it is nearly meaningless and for that reason should be avoided in any/all format efforts, preferring instead something more semantically specific such as "fn" (meaning full/formatted name of an item) or "summary" (when items are labeled more often with a short description/explanation rather than a name). [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* There's no use in lamenting about the existence of synonyms and homonyms. That's the real world - "in the wild", as you love to refer to it. Also the word "title" is not horribly overloaded, you're exaggerating here. It just happened that hCard were the first to use it, and in a way that's empirically much less important then the use of "title" as the heading of a resource. Still the real problem is that Microformats have only one namespace and no resolution mechanism for conflicts like this, beside "first come first served" - which is a very unsatisfying mechanism. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*#*# "fn" is [[existing-classes|defined]] as "the name of the object" which is pretty much what "recipe-title" means right now. So, whether we chose to keep this property, summary, or both, renaming "recipe-title" to "fn" would make sense. [[User:Yde|Yde]] 23:03, 16 January 2009 (UTC)
*#*#*#* the definition of "fn" in [[existing-classes|existing classes]] is maybe a little too short. "fn" is defined in hCard which is a reformulation of RFC 2462, which says: "Type name:FN - Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents. -Type special notes: This type is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object. - Type example: 'FN:Mr. John Q. Public\, Esq.'" (http://www.ietf.org/rfc/rfc2426.txt, on page 8). That clearly means a name of a person or an institution. and institution equals a juristical person, so "fn" semantically boils down to 'name of a person'. I wouldn't use that for every object. [[User:ThomasLoertsch|TomLurge]] 14:03, 20 January 2009 (UTC)
*#*#*#*# Thanks for the clarification. "fn" is definitely not a good idea. [[User:Yde|Yde]] 10:00, 23 January 2009 (UTC)
*#*#*#* on second thought: why not define a property "name"?! From my understanding of the english language (I'm not a native speaker) "name" is semantically generic enough to serve as a substitute for "title". Defining it rather broadly as "designation or title or denominator or heading of an item" would make it easily reusable. Plus we would have to explicitely discourage it's use for naming real or juristical persons and point to "fn" instead. [[User:ThomasLoertsch|TomLurge]] 12:21, 21 January 2009 (UTC)
*# '''Unnecessary recipe prefixing of summary property.''' Note: this is a re-opening of an issue from [[recipe-issues]]. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
*#* proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
*#* I agree principally but there are different "summary"s around: The [[hReview]]-Draft specifies a summary as "This optional field serves as a title for the review itself" while the [[hCalendar]] Draft refers to RFC 2445 which defines summary as "This property defines a short summary or subject for the calendar component". I certainly agree more with the semantics from RFC 2445 but referring to either of the two doesn't make much sense right now. Since you are editor of both hReview and hCalendar maybe you can clarify the subject? If hReview would be aligned with RFC 2445 then I would promote dropping the prefix.[[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#** Agreed, the definitions of "summary" across hCalendar and hReview could be better converged. Please add this as an issue to both [[hcalendar-issues]] and [[hreview-issues]] and I'll follow-up there accordingly. Given that is the path forward, let's fix this immediately in hRecipe now that the issue (and resolution) has been captured. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** I always prefer to leave other people some time (like some days) to make comments but if there will be no more comments I'll change "recipe-summary" to "summary" as defined in hCalender/RFC2445 durinng the next week. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*# '''preparation-time could re-use duration instead''' - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from [[hCalendar]] rather than introducing a new property name.
*#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
*#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
*#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** If that's possible than it's okay with me to reuse "duration" with the mentioned syntactic differences. But I'm not sure if it helps usability to overload properties in such a way. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#** The observation that preparation-time uses a nested "note" subproperty may actually reveal a problem with that approach itself, that is, perhaps instead of "preparation-time" with "value" and "note" subproperties, it may be better to refactor it as a "preparation" (an act thereof) with "duration" and "note" subproperties. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** While semantically correct this would leave us with one more property, since "preparation" on itself, without a "duration"-subelement, wouldn't make sense anymore. The real content that's of interest - the timespan needed - would reside only in the subelement. See [[recipe-issues]] for more discussion on this topic. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#* Also, if an hRecipe is nested within an hCalendar (e.g. a ''vtodo'' containing an hRecipe within the ''description''), we probably wouldn't want naïve hCalendar parsers using an hRecipe's cooking time as the entire duration of the hCalendar component. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
*#** This is a duplicate of similar issue(s) raised on hAudio and should be tracked there in [[haudio-issues]]. Parser implementation confusion/naïveté is insufficient to justify a corruption/compromise of the format. Data formats far outlast implementations. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#** I think the example is rather contrieved. I wouldn't expect microformats to handle such complex cases. I also agree with Tantek that a concise format is more important than naïve parsability. [[User:ThomasLoertsch|TomLurge]] 14:00, 20 January 2009 (UTC)
*#* Although there is no such thing as a "duration of a recipe" the semantics are close enough to justify the reuse of "duration" from [[hCalendar]]. But hCalender is just a refactoring of RFC 2445 which demands ISO style durations which are rather un-intuitive and I would be more concerend about implementors turned away by such requirements than by too many properties. RFC 2445 permits multiple duration values "if the property permits" so that should be fine. Result: I don't know... Btw: hCalender needs more love if it's really meant to be reused. "... editor's note: this list is incomplete (an incomplete list is better than no list) and is being currently edited from RFC2445 to here." imho is not good enough, especially not for a 'specification'. And RFC 2445 is not exactly an easy read. [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#** Agreed with the issues raised against hCalendar but please note them in [[hcalendar-issues]] for follow-up. Thanks! [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*# the issue is a little long already, but before i re-edit it and tear it apart into seperate subissues, i'd like to share what i think could become the draft 0.2. I replaced "recipe-title" with the new "name" (which is defined in a way to facilitate re-use and make the distinction to "fn" clear), replaced "recipe-summary" with "summary", replaced "num" and "unit" from the umfinished 'measure' with "type" and "value" from 'hCard' (i only recently discovered them...), replaced "method" (wihch is already used by [[hCalendar]] with "instructions" (see discussion at the issue "method" below), replaced "preparation-time" with "duration", deleted two "note"s for brevity, marked "summary", "nutrition", "author", "published" and "photo" as 'experimental' (meaning, that they may be removed from future drafts or the final specification, depending on experience and feedback from implementations) :
*# '''hrecipe'''. Proposal for Draft 0.2
*#** '''name''' required. text. [ comment for re-use: only for objects. use "fn" for persons and institutions. ]
*#** '''ingredient''' required. 1 or more. text with optional valid (x)HTML markup.
*#*** '''value''' and '''type'''. optional. re-used from [[hCard]].
*#** '''yield'''. optional. text.
*#** '''instructions'''. optional. text with optional valid (x)HTML markup.
*#** '''duration'''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
*#** '''''summary'''''. optional. text. re-used from [[hCalendar]]. [ ''experimental'' ]
*#** '''''nutrition'''''. optional. 1 or more. [ ''experimental'' ].
*#*** '''''value''''' and '''''type'''''. optional. re-used from [[hCard]]. [ ''experimental'' ].
*#** '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]]. [ ''experimental'' ].
*#** '''''published'''''. optional. re-used from [[hAtom]]. [ ''experimental'' ].
*#** '''''photo'''''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [ ''experimental'' ].
*#Please comment! [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
*#* I like this new schema. However I think the decision to replace "num", "unit", and "item" with "type" and "value" needs further explanation. Was it due to the fact that measure is unfinished? If so I think leaving "ingredient" and "nutrition" as text strings until measure is finished would be a better idea. The transition from "type"/"value" to measure will be difficult at a later point and I believe measure is more appropriate than re-using hCard. [[User:Yde|Yde]] 11:46, 23 January 2009 (UTC)
</div>

</div>
<div class="vevent">
* {{OpenIssue}} '''method''' 2008-01-17 raised by [[User:Yde|Yde]]
<div class="description">
*# Would it make sense to [[reuse]] [[hreview|hReview's]] "description" instead of hRecipe's "method" or is this stretching the semantics too far?
*#* I just discovered that hCalender uses "method", and with totally different semantics. So I guess we MUST change it. I'm not very happy with "description" though - that's a very unspecific term. Maybe "instructions", or "steps", or "preparation" , or "procedure"? They are all 'available'. I like "instructions" most, but since I'm not a native speaker I'm hesitant. Maybe the semantics are too different? Maybe "preparation" is better since we already almost have it (or had it - see the discussion about "preparation-time" -> "duration" above)? [[User:ThomasLoertsch|TomLurge]] 12:24, 21 January 2009 (UTC)
</div>
</div>

== resolved issues ==
<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''author is re-used from hAtom not hCard'''. minor issue. the "author" property is actually re-used from [[hAtom]] rather than hCard - hCard has no such property.
*#* Yikes! Corrected... [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
</div>
</div>

== closed issues ==
* none currently

===template===
{{issues-format}}

== related pages ==
* [[hRecipe]]
* [[hrecipe-feedback|hRecipe feedback]] for general feedback on hRecipe.
* [[recipe]] microformat effort development
* [[recipe-issues]] past issues raised and resolved during [[recipe-brainstorming]] towards the development of hRecipe.

hrecipe-issues

2009-01-23T11:46:25Z

Yde: /* issues */ Replace "num", "unit", "item"?

<entry-title>hRecipe issues</entry-title>

This page reflects issues raised about the [[hRecipe]] microformat.

Past issues captured during brainstorming towards hRecipe can be found in [[recipe-issues]].

Some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Please read this page (and [[recipe-issues]]) carefully ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

If you have general feedback on hRecipe (positive/neutral/negative) please add to [[hrecipe-feedback]] rather than this document.

== issues ==
Please add new issues to the '''bottom''' of this section by copy and pasting the [[hrecipe-issues#template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

<div class="vevent">
* {{OpenIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''Too many properties.''' From reviewing the [[recipe-examples]], it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
*#* btw: this is a first draft but a rather well worked out brainstorming proposal has been around for over a year, a refinement of it for another few months and the draft only builds on them. you are chiming in rather late - which is not a problem, but you should consider that a lot of thought already went into this format. [[User:ThomasLoertsch|TomLurge]] 14:05, 20 January 2009 (UTC)
*#* proposed resolution: Drop "recipe-title". In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by [[hCalendar]] (which got it from [[RFC2445]]), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
*#*# I tend to agree. There are definitely use cases for both "recipe-title/title/fn" and "recipe-summary/summary" - e.g. "[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ A Moroccan-ish Casserole]" sounds more like a summary while "[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti primavera]" is the full name or the title of the recipe. But the problem is, they would serve the same purpose. [[User:Yde|Yde]] 10:07, 17 January 2009 (UTC)
*#*#* These really are different things: the examples you give are both names/titles/labels/headings, though more or less descriptive. They are short, memorable and make the thing adressable by humans. A summary can be (and mostly is) much longer and serves a different purpose: it describes essential properties of the object at hand, eg: "this is easy and fast to prepare, but still looks impressive" or "the kids loved this last summer, but the ingredients can be hard to get" or "whenever i cook this i start to dream of ..." - whatever. these are summaries, abstracts, introductions. If "too many properties" are really a problem of hRecipe I could live without this property but I still think it makes sense. [[User:ThomasLoertsch|TomLurge]] 14:25, 20 January 2009 (UTC)
*#*#*# Right, that's actually how I thought of it before this whole "too many properties" issue. So on second thought, I believe "title/name" and "summary" are different things. [[User:Yde|Yde]] 11:22, 23 January 2009 (UTC)
*#* hRecipe certainly is not a very short format, but that stems from the complexity of the topic. Other seemingly simple issues like vCards also have a lot of properties. 'Nutrition' could be a candidate for a microformat on it's own - but then, since it can be reused anyway, why bother? If your issue leads to the proposal that we should keep this in mind and wait for implementations to prove the point then I agree - although of course I think that it's as short as reasonably possible.I disagree with the proposed resolution though - title and summary are different things and they are used differently in the real world. They are wo different elements in Dublin Core and I find no Thesaurus listing them together. Plus I personally am not aware of any recipes that don't have a title. The summary could be dropped but to what advantage since you are right with your next point and summary is already defined elsewhere? The real problem lies in the usage of 'title' in hCard and can't be solved by shoehorning other titles in something else. [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#*# Several problems with the reasoning above. First, assertion of "complexity of the topic" is insufficient. Per [[recipe-examples]] and rough 80% of the semantics implied therein - it is *not* a complex topic. Arguments from such data samples trumps any argument from theoretical complexity as we are going for a rough representation of real world use, not 99+% theoretical representation. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* Maybe "complex" is the wrong wording, but there certainly are a lot of properties to take into account. Anyway I would find it more helpfull if you could provide more insight what properties you specifically think are too much for a first draft. The only concrete example you give is the title, but you give no convincing argument for that. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*# "hCard has lots of properties" is an insufficient justification for breaking any principles as the principles were derived from some of the experience gained (lessons learned) from the development of the early microformats like hCard and hCalendar. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*# The use/assertion of "wait for implementation to prove the point" is assuming the wrong burden of proof. The burden of proof is to demonstrate the need for more complexity not less. That is, with microformats, we prefer starting smaller rather than larger. This is one of the [[principles]]. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*# I'm not taking these arguments lightly, but there are counter arguments too: while hCard and hCalender are extremly large vocabularies (which mostly stems from the approach taken of converting an existing vocab 1:1) it is also not necessarily helpfull to constrain a vocab by all means. when I'm looking for a vocabulary for a certain use I'm not looking for the smallest vocab but for theeon that fits my needs, more or less. if it's much too small I feel taht it's not of much help and I look somewhere else. the 80:20 rule might be a better guide, again. a vocabulary should encompass most of the usecases, and right from the start - since otherwise, why should it start to get adopted. it's right to start prudentious since it's always easier to add properties than to remove them. but don't exegerate, neither with minimization nor with exhaustiveness. for hrecipe i visited a lot of the big sites like recipetsar, which are full of user generated content. they use a lot of properties, certainly more than we do. a very minimal, but perfectly useful set of elements would be "name", "ingredients", "instructions". just those 3. but people upload pictures, socialize by stating their authorship, need to know how long preparation will take, care for nutritional information etc. so these properties are not just superfluous spaghetti vocabulary - they serve real needs, as you can see on those massively popular sites. so where's the sweet spot? 3 properties is extremely small, the 70 or so properties of hCard is extremely big. I think with about 10 properties hRecipe is not very big. you'll certainly not get lost in a soup of properties. and for implementors it's not too hard to go from 3 to 10 properties as long as they are not complexly nested/intertwined/constrained. 10 are certainly more than absolutely necessary - as I said, 3 would be my minimum -, so there's always room for debate and optimization. but please be specific, don't just argue with just "principles" and "lessons learned". [[User:ThomasLoertsch|TomLurge]] 11:08, 22 January 2009 (UTC)
*#*# Reasoning by analogy/justification of Dublin Core is insufficient, because schema should always be based on real world samples of *data* not on other formats. Also, the properties in Dublin Core are notoriously abstract/confusing/overloaded, and thus make a particularly poor base from which to reason from. Similarly reasoning from an abstract thesaurus definition is insufficient, as the thesaurus definition itself is not based on any sampling of real world publication data. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* So you're suggesting that Dublin Core or a Thesaurus are not based on real world data but are made up out of the abstract while only the real world examples gathered on this site are the real deal? Well... I don't see what's so very special about the microformats process that it can singlehandedly negate all the work other people have done. I can add some examples to the examples page, from sites that together make up the vast majority of recipes on the (english speaking) net (both by number and by visits). You'll find all the properties mentioned in the hRecipe format (and you'll certainly find that they all have a title). And I just double-checked the [[recipe-examples]] page: 'all' the recipe examples there have a title and in all but one cases it is called "title" too. It's very helpfull to have some process but almost all your argumentation centers around the process while you provide very little concrete criticism on the properties themselves. [[User:ThomasLoertsch|TomLurge]] 14:08, 20 January 2009 (UTC)
*#*# Reasoning by absence of negative is flawed: "am not aware of any recipes that don't have a title" - absence of a negative cannot be used to prove an assertion to be true, only the possibility of being true. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* Get your logics right: double negation is the opposite of negation. You can easily reformulate my assertion to: "Almost all recipes I'm aware of do have a title". [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*# Finally, the "real" problem is not the use of "title" within hCard but rather that the term "title" has been so horribly overloaded across formats, vocabularies that it is nearly meaningless and for that reason should be avoided in any/all format efforts, preferring instead something more semantically specific such as "fn" (meaning full/formatted name of an item) or "summary" (when items are labeled more often with a short description/explanation rather than a name). [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* There's no use in lamenting about the existence of synonyms and homonyms. That's the real world - "in the wild", as you love to refer to it. Also the word "title" is not horribly overloaded, you're exaggerating here. It just happened that hCard were the first to use it, and in a way that's empirically much less important then the use of "title" as the heading of a resource. Still the real problem is that Microformats have only one namespace and no resolution mechanism for conflicts like this, beside "first come first served" - which is a very unsatisfying mechanism. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*#*# "fn" is [[existing-classes|defined]] as "the name of the object" which is pretty much what "recipe-title" means right now. So, whether we chose to keep this property, summary, or both, renaming "recipe-title" to "fn" would make sense. [[User:Yde|Yde]] 23:03, 16 January 2009 (UTC)
*#*#*#* the definition of "fn" in [[existing-classes|existing classes]] is maybe a little too short. "fn" is defined in hCard which is a reformulation of RFC 2462, which says: "Type name:FN - Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents. -Type special notes: This type is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object. - Type example: 'FN:Mr. John Q. Public\, Esq.'" (http://www.ietf.org/rfc/rfc2426.txt, on page 8). That clearly means a name of a person or an institution. and institution equals a juristical person, so "fn" semantically boils down to 'name of a person'. I wouldn't use that for every object. [[User:ThomasLoertsch|TomLurge]] 14:03, 20 January 2009 (UTC)
*#*#*#*# Thanks for the clarification. "fn" is definitely not a good idea. [[User:Yde|Yde]] 10:00, 23 January 2009 (UTC)
*#*#*#* on second thought: why not define a property "name"?! From my understanding of the english language (I'm not a native speaker) "name" is semantically generic enough to serve as a substitute for "title". Defining it rather broadly as "designation or title or denominator or heading of an item" would make it easily reusable. Plus we would have to explicitely discourage it's use for naming real or juristical persons and point to "fn" instead. [[User:ThomasLoertsch|TomLurge]] 12:21, 21 January 2009 (UTC)
*# '''Unnecessary recipe prefixing of summary property.''' Note: this is a re-opening of an issue from [[recipe-issues]]. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
*#* proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
*#* I agree principally but there are different "summary"s around: The [[hReview]]-Draft specifies a summary as "This optional field serves as a title for the review itself" while the [[hCalendar]] Draft refers to RFC 2445 which defines summary as "This property defines a short summary or subject for the calendar component". I certainly agree more with the semantics from RFC 2445 but referring to either of the two doesn't make much sense right now. Since you are editor of both hReview and hCalendar maybe you can clarify the subject? If hReview would be aligned with RFC 2445 then I would promote dropping the prefix.[[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#** Agreed, the definitions of "summary" across hCalendar and hReview could be better converged. Please add this as an issue to both [[hcalendar-issues]] and [[hreview-issues]] and I'll follow-up there accordingly. Given that is the path forward, let's fix this immediately in hRecipe now that the issue (and resolution) has been captured. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** I always prefer to leave other people some time (like some days) to make comments but if there will be no more comments I'll change "recipe-summary" to "summary" as defined in hCalender/RFC2445 durinng the next week. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*# '''preparation-time could re-use duration instead''' - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from [[hCalendar]] rather than introducing a new property name.
*#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
*#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
*#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** If that's possible than it's okay with me to reuse "duration" with the mentioned syntactic differences. But I'm not sure if it helps usability to overload properties in such a way. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#** The observation that preparation-time uses a nested "note" subproperty may actually reveal a problem with that approach itself, that is, perhaps instead of "preparation-time" with "value" and "note" subproperties, it may be better to refactor it as a "preparation" (an act thereof) with "duration" and "note" subproperties. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** While semantically correct this would leave us with one more property, since "preparation" on itself, without a "duration"-subelement, wouldn't make sense anymore. The real content that's of interest - the timespan needed - would reside only in the subelement. See [[recipe-issues]] for more discussion on this topic. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#* Also, if an hRecipe is nested within an hCalendar (e.g. a ''vtodo'' containing an hRecipe within the ''description''), we probably wouldn't want naïve hCalendar parsers using an hRecipe's cooking time as the entire duration of the hCalendar component. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
*#** This is a duplicate of similar issue(s) raised on hAudio and should be tracked there in [[haudio-issues]]. Parser implementation confusion/naïveté is insufficient to justify a corruption/compromise of the format. Data formats far outlast implementations. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#** I think the example is rather contrieved. I wouldn't expect microformats to handle such complex cases. I also agree with Tantek that a concise format is more important than naïve parsability. [[User:ThomasLoertsch|TomLurge]] 14:00, 20 January 2009 (UTC)
*#* Although there is no such thing as a "duration of a recipe" the semantics are close enough to justify the reuse of "duration" from [[hCalendar]]. But hCalender is just a refactoring of RFC 2445 which demands ISO style durations which are rather un-intuitive and I would be more concerend about implementors turned away by such requirements than by too many properties. RFC 2445 permits multiple duration values "if the property permits" so that should be fine. Result: I don't know... Btw: hCalender needs more love if it's really meant to be reused. "... editor's note: this list is incomplete (an incomplete list is better than no list) and is being currently edited from RFC2445 to here." imho is not good enough, especially not for a 'specification'. And RFC 2445 is not exactly an easy read. [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#** Agreed with the issues raised against hCalendar but please note them in [[hcalendar-issues]] for follow-up. Thanks! [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*# the issue is a little long already, but before i re-edit it and tear it apart into seperate subissues, i'd like to share what i think could become the draft 0.2. I replaced "recipe-title" with the new "name" (which is defined in a way to facilitate re-use and make the distinction to "fn" clear), replaced "recipe-summary" with "summary", replaced "num" and "unit" from the umfinished 'measure' with "type" and "value" from 'hCard' (i only recently discovered them...), replaced "method" (wihch is already used by [[hCalendar]] with "instructions" (see discussion at the issue "method" below), replaced "preparation-time" with "duration", deleted two "note"s for brevity, marked "summary", "nutrition", "author", "published" and "photo" as 'experimental' (meaning, that they may be removed from future drafts or the final specification, depending on experience and feedback from implementations) :
*# '''hrecipe'''. Proposal for Draft 0.2
*#** '''name''' required. text. [ comment for re-use: only for objects. use "fn" for persons and institutions. ]
*#** '''ingredient''' required. 1 or more. text with optional valid (x)HTML markup.
*#*** '''value''' and '''type'''. optional. re-used from [[hCard]].
*#** '''yield'''. optional. text.
*#** '''instructions'''. optional. text with optional valid (x)HTML markup.
*#** '''duration'''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
*#** '''''summary'''''. optional. text. re-used from [[hCalendar]]. [ ''experimental'' ]
*#** '''''nutrition'''''. optional. 1 or more. [ ''experimental'' ].
*#*** '''''value''''' and '''''type'''''. optional. re-used from [[hCard]]. [ ''experimental'' ].
*#** '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]]. [ ''experimental'' ].
*#** '''''published'''''. optional. re-used from [[hAtom]]. [ ''experimental'' ].
*#** '''''photo'''''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [ ''experimental'' ].
*#Please comment! [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
*#* I like this new schema. However I think the decision to replace "num", "unit", and "item" with "type" and "value" needs further explanation. Was it due to the fact that measure is unfinished? If so I think leaving "ingredient" as a text string until measure is finished would be a better idea. The transition from "type"/"value" to measure will be difficult at a later point and I believe measure is more appropriate than re-using hCard. [[User:Yde|Yde]] 11:46, 23 January 2009 (UTC)
</div>

</div>
<div class="vevent">
* {{OpenIssue}} '''method''' 2008-01-17 raised by [[User:Yde|Yde]]
<div class="description">
*# Would it make sense to [[reuse]] [[hreview|hReview's]] "description" instead of hRecipe's "method" or is this stretching the semantics too far?
*#* I just discovered that hCalender uses "method", and with totally different semantics. So I guess we MUST change it. I'm not very happy with "description" though - that's a very unspecific term. Maybe "instructions", or "steps", or "preparation" , or "procedure"? They are all 'available'. I like "instructions" most, but since I'm not a native speaker I'm hesitant. Maybe the semantics are too different? Maybe "preparation" is better since we already almost have it (or had it - see the discussion about "preparation-time" -> "duration" above)? [[User:ThomasLoertsch|TomLurge]] 12:24, 21 January 2009 (UTC)
</div>
</div>

== resolved issues ==
<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''author is re-used from hAtom not hCard'''. minor issue. the "author" property is actually re-used from [[hAtom]] rather than hCard - hCard has no such property.
*#* Yikes! Corrected... [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
</div>
</div>

== closed issues ==
* none currently

===template===
{{issues-format}}

== related pages ==
* [[hRecipe]]
* [[hrecipe-feedback|hRecipe feedback]] for general feedback on hRecipe.
* [[recipe]] microformat effort development
* [[recipe-issues]] past issues raised and resolved during [[recipe-brainstorming]] towards the development of hRecipe.

hrecipe-issues

2009-01-23T11:22:35Z

Yde: /* issues */ Name/summary?

<entry-title>hRecipe issues</entry-title>

This page reflects issues raised about the [[hRecipe]] microformat.

Past issues captured during brainstorming towards hRecipe can be found in [[recipe-issues]].

Some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Please read this page (and [[recipe-issues]]) carefully ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

If you have general feedback on hRecipe (positive/neutral/negative) please add to [[hrecipe-feedback]] rather than this document.

== issues ==
Please add new issues to the '''bottom''' of this section by copy and pasting the [[hrecipe-issues#template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

<div class="vevent">
* {{OpenIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''Too many properties.''' From reviewing the [[recipe-examples]], it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
*#* btw: this is a first draft but a rather well worked out brainstorming proposal has been around for over a year, a refinement of it for another few months and the draft only builds on them. you are chiming in rather late - which is not a problem, but you should consider that a lot of thought already went into this format. [[User:ThomasLoertsch|TomLurge]] 14:05, 20 January 2009 (UTC)
*#* proposed resolution: Drop "recipe-title". In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by [[hCalendar]] (which got it from [[RFC2445]]), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
*#*# I tend to agree. There are definitely use cases for both "recipe-title/title/fn" and "recipe-summary/summary" - e.g. "[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ A Moroccan-ish Casserole]" sounds more like a summary while "[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti primavera]" is the full name or the title of the recipe. But the problem is, they would serve the same purpose. [[User:Yde|Yde]] 10:07, 17 January 2009 (UTC)
*#*#* These really are different things: the examples you give are both names/titles/labels/headings, though more or less descriptive. They are short, memorable and make the thing adressable by humans. A summary can be (and mostly is) much longer and serves a different purpose: it describes essential properties of the object at hand, eg: "this is easy and fast to prepare, but still looks impressive" or "the kids loved this last summer, but the ingredients can be hard to get" or "whenever i cook this i start to dream of ..." - whatever. these are summaries, abstracts, introductions. If "too many properties" are really a problem of hRecipe I could live without this property but I still think it makes sense. [[User:ThomasLoertsch|TomLurge]] 14:25, 20 January 2009 (UTC)
*#*#*# Right, that's actually how I thought of it before this whole "too many properties" issue. So on second thought, I believe "title/name" and "summary" are different things. [[User:Yde|Yde]] 11:22, 23 January 2009 (UTC)
*#* hRecipe certainly is not a very short format, but that stems from the complexity of the topic. Other seemingly simple issues like vCards also have a lot of properties. 'Nutrition' could be a candidate for a microformat on it's own - but then, since it can be reused anyway, why bother? If your issue leads to the proposal that we should keep this in mind and wait for implementations to prove the point then I agree - although of course I think that it's as short as reasonably possible.I disagree with the proposed resolution though - title and summary are different things and they are used differently in the real world. They are wo different elements in Dublin Core and I find no Thesaurus listing them together. Plus I personally am not aware of any recipes that don't have a title. The summary could be dropped but to what advantage since you are right with your next point and summary is already defined elsewhere? The real problem lies in the usage of 'title' in hCard and can't be solved by shoehorning other titles in something else. [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#*# Several problems with the reasoning above. First, assertion of "complexity of the topic" is insufficient. Per [[recipe-examples]] and rough 80% of the semantics implied therein - it is *not* a complex topic. Arguments from such data samples trumps any argument from theoretical complexity as we are going for a rough representation of real world use, not 99+% theoretical representation. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* Maybe "complex" is the wrong wording, but there certainly are a lot of properties to take into account. Anyway I would find it more helpfull if you could provide more insight what properties you specifically think are too much for a first draft. The only concrete example you give is the title, but you give no convincing argument for that. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*# "hCard has lots of properties" is an insufficient justification for breaking any principles as the principles were derived from some of the experience gained (lessons learned) from the development of the early microformats like hCard and hCalendar. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*# The use/assertion of "wait for implementation to prove the point" is assuming the wrong burden of proof. The burden of proof is to demonstrate the need for more complexity not less. That is, with microformats, we prefer starting smaller rather than larger. This is one of the [[principles]]. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*# I'm not taking these arguments lightly, but there are counter arguments too: while hCard and hCalender are extremly large vocabularies (which mostly stems from the approach taken of converting an existing vocab 1:1) it is also not necessarily helpfull to constrain a vocab by all means. when I'm looking for a vocabulary for a certain use I'm not looking for the smallest vocab but for theeon that fits my needs, more or less. if it's much too small I feel taht it's not of much help and I look somewhere else. the 80:20 rule might be a better guide, again. a vocabulary should encompass most of the usecases, and right from the start - since otherwise, why should it start to get adopted. it's right to start prudentious since it's always easier to add properties than to remove them. but don't exegerate, neither with minimization nor with exhaustiveness. for hrecipe i visited a lot of the big sites like recipetsar, which are full of user generated content. they use a lot of properties, certainly more than we do. a very minimal, but perfectly useful set of elements would be "name", "ingredients", "instructions". just those 3. but people upload pictures, socialize by stating their authorship, need to know how long preparation will take, care for nutritional information etc. so these properties are not just superfluous spaghetti vocabulary - they serve real needs, as you can see on those massively popular sites. so where's the sweet spot? 3 properties is extremely small, the 70 or so properties of hCard is extremely big. I think with about 10 properties hRecipe is not very big. you'll certainly not get lost in a soup of properties. and for implementors it's not too hard to go from 3 to 10 properties as long as they are not complexly nested/intertwined/constrained. 10 are certainly more than absolutely necessary - as I said, 3 would be my minimum -, so there's always room for debate and optimization. but please be specific, don't just argue with just "principles" and "lessons learned". [[User:ThomasLoertsch|TomLurge]] 11:08, 22 January 2009 (UTC)
*#*# Reasoning by analogy/justification of Dublin Core is insufficient, because schema should always be based on real world samples of *data* not on other formats. Also, the properties in Dublin Core are notoriously abstract/confusing/overloaded, and thus make a particularly poor base from which to reason from. Similarly reasoning from an abstract thesaurus definition is insufficient, as the thesaurus definition itself is not based on any sampling of real world publication data. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* So you're suggesting that Dublin Core or a Thesaurus are not based on real world data but are made up out of the abstract while only the real world examples gathered on this site are the real deal? Well... I don't see what's so very special about the microformats process that it can singlehandedly negate all the work other people have done. I can add some examples to the examples page, from sites that together make up the vast majority of recipes on the (english speaking) net (both by number and by visits). You'll find all the properties mentioned in the hRecipe format (and you'll certainly find that they all have a title). And I just double-checked the [[recipe-examples]] page: 'all' the recipe examples there have a title and in all but one cases it is called "title" too. It's very helpfull to have some process but almost all your argumentation centers around the process while you provide very little concrete criticism on the properties themselves. [[User:ThomasLoertsch|TomLurge]] 14:08, 20 January 2009 (UTC)
*#*# Reasoning by absence of negative is flawed: "am not aware of any recipes that don't have a title" - absence of a negative cannot be used to prove an assertion to be true, only the possibility of being true. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* Get your logics right: double negation is the opposite of negation. You can easily reformulate my assertion to: "Almost all recipes I'm aware of do have a title". [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*# Finally, the "real" problem is not the use of "title" within hCard but rather that the term "title" has been so horribly overloaded across formats, vocabularies that it is nearly meaningless and for that reason should be avoided in any/all format efforts, preferring instead something more semantically specific such as "fn" (meaning full/formatted name of an item) or "summary" (when items are labeled more often with a short description/explanation rather than a name). [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* There's no use in lamenting about the existence of synonyms and homonyms. That's the real world - "in the wild", as you love to refer to it. Also the word "title" is not horribly overloaded, you're exaggerating here. It just happened that hCard were the first to use it, and in a way that's empirically much less important then the use of "title" as the heading of a resource. Still the real problem is that Microformats have only one namespace and no resolution mechanism for conflicts like this, beside "first come first served" - which is a very unsatisfying mechanism. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*#*# "fn" is [[existing-classes|defined]] as "the name of the object" which is pretty much what "recipe-title" means right now. So, whether we chose to keep this property, summary, or both, renaming "recipe-title" to "fn" would make sense. [[User:Yde|Yde]] 23:03, 16 January 2009 (UTC)
*#*#*#* the definition of "fn" in [[existing-classes|existing classes]] is maybe a little too short. "fn" is defined in hCard which is a reformulation of RFC 2462, which says: "Type name:FN - Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents. -Type special notes: This type is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object. - Type example: 'FN:Mr. John Q. Public\, Esq.'" (http://www.ietf.org/rfc/rfc2426.txt, on page 8). That clearly means a name of a person or an institution. and institution equals a juristical person, so "fn" semantically boils down to 'name of a person'. I wouldn't use that for every object. [[User:ThomasLoertsch|TomLurge]] 14:03, 20 January 2009 (UTC)
*#*#*#*# Thanks for the clarification. "fn" is definitely not a good idea. [[User:Yde|Yde]] 10:00, 23 January 2009 (UTC)
*#*#*#* on second thought: why not define a property "name"?! From my understanding of the english language (I'm not a native speaker) "name" is semantically generic enough to serve as a substitute for "title". Defining it rather broadly as "designation or title or denominator or heading of an item" would make it easily reusable. Plus we would have to explicitely discourage it's use for naming real or juristical persons and point to "fn" instead. [[User:ThomasLoertsch|TomLurge]] 12:21, 21 January 2009 (UTC)
*# '''Unnecessary recipe prefixing of summary property.''' Note: this is a re-opening of an issue from [[recipe-issues]]. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
*#* proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
*#* I agree principally but there are different "summary"s around: The [[hReview]]-Draft specifies a summary as "This optional field serves as a title for the review itself" while the [[hCalendar]] Draft refers to RFC 2445 which defines summary as "This property defines a short summary or subject for the calendar component". I certainly agree more with the semantics from RFC 2445 but referring to either of the two doesn't make much sense right now. Since you are editor of both hReview and hCalendar maybe you can clarify the subject? If hReview would be aligned with RFC 2445 then I would promote dropping the prefix.[[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#** Agreed, the definitions of "summary" across hCalendar and hReview could be better converged. Please add this as an issue to both [[hcalendar-issues]] and [[hreview-issues]] and I'll follow-up there accordingly. Given that is the path forward, let's fix this immediately in hRecipe now that the issue (and resolution) has been captured. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** I always prefer to leave other people some time (like some days) to make comments but if there will be no more comments I'll change "recipe-summary" to "summary" as defined in hCalender/RFC2445 durinng the next week. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*# '''preparation-time could re-use duration instead''' - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from [[hCalendar]] rather than introducing a new property name.
*#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
*#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
*#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** If that's possible than it's okay with me to reuse "duration" with the mentioned syntactic differences. But I'm not sure if it helps usability to overload properties in such a way. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#** The observation that preparation-time uses a nested "note" subproperty may actually reveal a problem with that approach itself, that is, perhaps instead of "preparation-time" with "value" and "note" subproperties, it may be better to refactor it as a "preparation" (an act thereof) with "duration" and "note" subproperties. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** While semantically correct this would leave us with one more property, since "preparation" on itself, without a "duration"-subelement, wouldn't make sense anymore. The real content that's of interest - the timespan needed - would reside only in the subelement. See [[recipe-issues]] for more discussion on this topic. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#* Also, if an hRecipe is nested within an hCalendar (e.g. a ''vtodo'' containing an hRecipe within the ''description''), we probably wouldn't want naïve hCalendar parsers using an hRecipe's cooking time as the entire duration of the hCalendar component. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
*#** This is a duplicate of similar issue(s) raised on hAudio and should be tracked there in [[haudio-issues]]. Parser implementation confusion/naïveté is insufficient to justify a corruption/compromise of the format. Data formats far outlast implementations. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#** I think the example is rather contrieved. I wouldn't expect microformats to handle such complex cases. I also agree with Tantek that a concise format is more important than naïve parsability. [[User:ThomasLoertsch|TomLurge]] 14:00, 20 January 2009 (UTC)
*#* Although there is no such thing as a "duration of a recipe" the semantics are close enough to justify the reuse of "duration" from [[hCalendar]]. But hCalender is just a refactoring of RFC 2445 which demands ISO style durations which are rather un-intuitive and I would be more concerend about implementors turned away by such requirements than by too many properties. RFC 2445 permits multiple duration values "if the property permits" so that should be fine. Result: I don't know... Btw: hCalender needs more love if it's really meant to be reused. "... editor's note: this list is incomplete (an incomplete list is better than no list) and is being currently edited from RFC2445 to here." imho is not good enough, especially not for a 'specification'. And RFC 2445 is not exactly an easy read. [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#** Agreed with the issues raised against hCalendar but please note them in [[hcalendar-issues]] for follow-up. Thanks! [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*# the issue is a little long already, but before i re-edit it and tear it apart into seperate subissues, i'd like to share what i think could become the draft 0.2. I replaced "recipe-title" with the new "name" (which is defined in a way to facilitate re-use and make the distinction to "fn" clear), replaced "recipe-summary" with "summary", replaced "num" and "unit" from the umfinished 'measure' with "type" and "value" from 'hCard' (i only recently discovered them...), replaced "method" (wihch is already used by [[hCalendar]] with "instructions" (see discussion at the issue "method" below), replaced "preparation-time" with "duration", deleted two "note"s for brevity, marked "summary", "nutrition", "author", "published" and "photo" as 'experimental' (meaning, that they may be removed from future drafts or the final specification, depending on experience and feedback from implementations) :
*# '''hrecipe'''. Proposal for Draft 0.2
*#** '''name''' required. text. [ comment for re-use: only for objects. use "fn" for persons and institutions. ]
*#** '''ingredient''' required. 1 or more. text with optional valid (x)HTML markup.
*#*** '''value''' and '''type'''. optional. re-used from [[hCard]].
*#** '''yield'''. optional. text.
*#** '''instructions'''. optional. text with optional valid (x)HTML markup.
*#** '''duration'''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
*#** '''''summary'''''. optional. text. re-used from [[hCalendar]]. [ ''experimental'' ]
*#** '''''nutrition'''''. optional. 1 or more. [ ''experimental'' ].
*#*** '''''value''''' and '''''type'''''. optional. re-used from [[hCard]]. [ ''experimental'' ].
*#** '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]]. [ ''experimental'' ].
*#** '''''published'''''. optional. re-used from [[hAtom]]. [ ''experimental'' ].
*#** '''''photo'''''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [ ''experimental'' ].
Please comment! [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
</div>

</div>
<div class="vevent">
* {{OpenIssue}} '''method''' 2008-01-17 raised by [[User:Yde|Yde]]
<div class="description">
*# Would it make sense to [[reuse]] [[hreview|hReview's]] "description" instead of hRecipe's "method" or is this stretching the semantics too far?
*#* I just discovered that hCalender uses "method", and with totally different semantics. So I guess we MUST change it. I'm not very happy with "description" though - that's a very unspecific term. Maybe "instructions", or "steps", or "preparation" , or "procedure"? They are all 'available'. I like "instructions" most, but since I'm not a native speaker I'm hesitant. Maybe the semantics are too different? Maybe "preparation" is better since we already almost have it (or had it - see the discussion about "preparation-time" -> "duration" above)? [[User:ThomasLoertsch|TomLurge]] 12:24, 21 January 2009 (UTC)
</div>
</div>

== resolved issues ==
<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''author is re-used from hAtom not hCard'''. minor issue. the "author" property is actually re-used from [[hAtom]] rather than hCard - hCard has no such property.
*#* Yikes! Corrected... [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
</div>
</div>

== closed issues ==
* none currently

===template===
{{issues-format}}

== related pages ==
* [[hRecipe]]
* [[hrecipe-feedback|hRecipe feedback]] for general feedback on hRecipe.
* [[recipe]] microformat effort development
* [[recipe-issues]] past issues raised and resolved during [[recipe-brainstorming]] towards the development of hRecipe.

hrecipe-issues

2009-01-23T10:00:45Z

Yde: /* issues */

<entry-title>hRecipe issues</entry-title>

This page reflects issues raised about the [[hRecipe]] microformat.

Past issues captured during brainstorming towards hRecipe can be found in [[recipe-issues]].

Some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Please read this page (and [[recipe-issues]]) carefully ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

If you have general feedback on hRecipe (positive/neutral/negative) please add to [[hrecipe-feedback]] rather than this document.

== issues ==
Please add new issues to the '''bottom''' of this section by copy and pasting the [[hrecipe-issues#template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

<div class="vevent">
* {{OpenIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''Too many properties.''' From reviewing the [[recipe-examples]], it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
*#* btw: this is a first draft but a rather well worked out brainstorming proposal has been around for over a year, a refinement of it for another few months and the draft only builds on them. you are chiming in rather late - which is not a problem, but you should consider that a lot of thought already went into this format. [[User:ThomasLoertsch|TomLurge]] 14:05, 20 January 2009 (UTC)
*#* proposed resolution: Drop "recipe-title". In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by [[hCalendar]] (which got it from [[RFC2445]]), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
*#*# I tend to agree. There are definitely use cases for both "recipe-title/title/fn" and "recipe-summary/summary" - e.g. "[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ A Moroccan-ish Casserole]" sounds more like a summary while "[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti primavera]" is the full name or the title of the recipe. But the problem is, they would serve the same purpose. [[User:Yde|Yde]] 10:07, 17 January 2009 (UTC)
*#*#* These really are different things: the examples you give are both names/titles/labels/headings, though more or less descriptive. They are short, memorable and make the thing adressable by humans. A summary can be (and mostly is) much longer and serves a different purpose: it describes essential properties of the object at hand, eg: "this is easy and fast to prepare, but still looks impressive" or "the kids loved this last summer, but the ingredients can be hard to get" or "whenever i cook this i start to dream of ..." - whatever. these are summaries, abstracts, introductions. If "too many properties" are really a problem of hRecipe I could live without this property but I still think it makes sense. [[User:ThomasLoertsch|TomLurge]] 14:25, 20 January 2009 (UTC)
*#* hRecipe certainly is not a very short format, but that stems from the complexity of the topic. Other seemingly simple issues like vCards also have a lot of properties. 'Nutrition' could be a candidate for a microformat on it's own - but then, since it can be reused anyway, why bother? If your issue leads to the proposal that we should keep this in mind and wait for implementations to prove the point then I agree - although of course I think that it's as short as reasonably possible.I disagree with the proposed resolution though - title and summary are different things and they are used differently in the real world. They are wo different elements in Dublin Core and I find no Thesaurus listing them together. Plus I personally am not aware of any recipes that don't have a title. The summary could be dropped but to what advantage since you are right with your next point and summary is already defined elsewhere? The real problem lies in the usage of 'title' in hCard and can't be solved by shoehorning other titles in something else. [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#*# Several problems with the reasoning above. First, assertion of "complexity of the topic" is insufficient. Per [[recipe-examples]] and rough 80% of the semantics implied therein - it is *not* a complex topic. Arguments from such data samples trumps any argument from theoretical complexity as we are going for a rough representation of real world use, not 99+% theoretical representation. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* Maybe "complex" is the wrong wording, but there certainly are a lot of properties to take into account. Anyway I would find it more helpfull if you could provide more insight what properties you specifically think are too much for a first draft. The only concrete example you give is the title, but you give no convincing argument for that. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*# "hCard has lots of properties" is an insufficient justification for breaking any principles as the principles were derived from some of the experience gained (lessons learned) from the development of the early microformats like hCard and hCalendar. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*# The use/assertion of "wait for implementation to prove the point" is assuming the wrong burden of proof. The burden of proof is to demonstrate the need for more complexity not less. That is, with microformats, we prefer starting smaller rather than larger. This is one of the [[principles]]. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*# I'm not taking these arguments lightly, but there are counter arguments too: while hCard and hCalender are extremly large vocabularies (which mostly stems from the approach taken of converting an existing vocab 1:1) it is also not necessarily helpfull to constrain a vocab by all means. when I'm looking for a vocabulary for a certain use I'm not looking for the smallest vocab but for theeon that fits my needs, more or less. if it's much too small I feel taht it's not of much help and I look somewhere else. the 80:20 rule might be a better guide, again. a vocabulary should encompass most of the usecases, and right from the start - since otherwise, why should it start to get adopted. it's right to start prudentious since it's always easier to add properties than to remove them. but don't exegerate, neither with minimization nor with exhaustiveness. for hrecipe i visited a lot of the big sites like recipetsar, which are full of user generated content. they use a lot of properties, certainly more than we do. a very minimal, but perfectly useful set of elements would be "name", "ingredients", "instructions". just those 3. but people upload pictures, socialize by stating their authorship, need to know how long preparation will take, care for nutritional information etc. so these properties are not just superfluous spaghetti vocabulary - they serve real needs, as you can see on those massively popular sites. so where's the sweet spot? 3 properties is extremely small, the 70 or so properties of hCard is extremely big. I think with about 10 properties hRecipe is not very big. you'll certainly not get lost in a soup of properties. and for implementors it's not too hard to go from 3 to 10 properties as long as they are not complexly nested/intertwined/constrained. 10 are certainly more than absolutely necessary - as I said, 3 would be my minimum -, so there's always room for debate and optimization. but please be specific, don't just argue with just "principles" and "lessons learned". [[User:ThomasLoertsch|TomLurge]] 11:08, 22 January 2009 (UTC)
*#*# Reasoning by analogy/justification of Dublin Core is insufficient, because schema should always be based on real world samples of *data* not on other formats. Also, the properties in Dublin Core are notoriously abstract/confusing/overloaded, and thus make a particularly poor base from which to reason from. Similarly reasoning from an abstract thesaurus definition is insufficient, as the thesaurus definition itself is not based on any sampling of real world publication data. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* So you're suggesting that Dublin Core or a Thesaurus are not based on real world data but are made up out of the abstract while only the real world examples gathered on this site are the real deal? Well... I don't see what's so very special about the microformats process that it can singlehandedly negate all the work other people have done. I can add some examples to the examples page, from sites that together make up the vast majority of recipes on the (english speaking) net (both by number and by visits). You'll find all the properties mentioned in the hRecipe format (and you'll certainly find that they all have a title). And I just double-checked the [[recipe-examples]] page: 'all' the recipe examples there have a title and in all but one cases it is called "title" too. It's very helpfull to have some process but almost all your argumentation centers around the process while you provide very little concrete criticism on the properties themselves. [[User:ThomasLoertsch|TomLurge]] 14:08, 20 January 2009 (UTC)
*#*# Reasoning by absence of negative is flawed: "am not aware of any recipes that don't have a title" - absence of a negative cannot be used to prove an assertion to be true, only the possibility of being true. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* Get your logics right: double negation is the opposite of negation. You can easily reformulate my assertion to: "Almost all recipes I'm aware of do have a title". [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*# Finally, the "real" problem is not the use of "title" within hCard but rather that the term "title" has been so horribly overloaded across formats, vocabularies that it is nearly meaningless and for that reason should be avoided in any/all format efforts, preferring instead something more semantically specific such as "fn" (meaning full/formatted name of an item) or "summary" (when items are labeled more often with a short description/explanation rather than a name). [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*#* There's no use in lamenting about the existence of synonyms and homonyms. That's the real world - "in the wild", as you love to refer to it. Also the word "title" is not horribly overloaded, you're exaggerating here. It just happened that hCard were the first to use it, and in a way that's empirically much less important then the use of "title" as the heading of a resource. Still the real problem is that Microformats have only one namespace and no resolution mechanism for conflicts like this, beside "first come first served" - which is a very unsatisfying mechanism. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#*#*# "fn" is [[existing-classes|defined]] as "the name of the object" which is pretty much what "recipe-title" means right now. So, whether we chose to keep this property, summary, or both, renaming "recipe-title" to "fn" would make sense. [[User:Yde|Yde]] 23:03, 16 January 2009 (UTC)
*#*#*#* the definition of "fn" in [[existing-classes|existing classes]] is maybe a little too short. "fn" is defined in hCard which is a reformulation of RFC 2462, which says: "Type name:FN - Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents. -Type special notes: This type is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object. - Type example: 'FN:Mr. John Q. Public\, Esq.'" (http://www.ietf.org/rfc/rfc2426.txt, on page 8). That clearly means a name of a person or an institution. and institution equals a juristical person, so "fn" semantically boils down to 'name of a person'. I wouldn't use that for every object. [[User:ThomasLoertsch|TomLurge]] 14:03, 20 January 2009 (UTC)
*#*#*#*# Thanks for the clarification. "fn" is definitely not a good idea. [[User:Yde|Yde]] 10:00, 23 January 2009 (UTC)
*#*#*#* on second thought: why not define a property "name"?! From my understanding of the english language (I'm not a native speaker) "name" is semantically generic enough to serve as a substitute for "title". Defining it rather broadly as "designation or title or denominator or heading of an item" would make it easily reusable. Plus we would have to explicitely discourage it's use for naming real or juristical persons and point to "fn" instead. [[User:ThomasLoertsch|TomLurge]] 12:21, 21 January 2009 (UTC)
*# '''Unnecessary recipe prefixing of summary property.''' Note: this is a re-opening of an issue from [[recipe-issues]]. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
*#* proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
*#* I agree principally but there are different "summary"s around: The [[hReview]]-Draft specifies a summary as "This optional field serves as a title for the review itself" while the [[hCalendar]] Draft refers to RFC 2445 which defines summary as "This property defines a short summary or subject for the calendar component". I certainly agree more with the semantics from RFC 2445 but referring to either of the two doesn't make much sense right now. Since you are editor of both hReview and hCalendar maybe you can clarify the subject? If hReview would be aligned with RFC 2445 then I would promote dropping the prefix.[[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#** Agreed, the definitions of "summary" across hCalendar and hReview could be better converged. Please add this as an issue to both [[hcalendar-issues]] and [[hreview-issues]] and I'll follow-up there accordingly. Given that is the path forward, let's fix this immediately in hRecipe now that the issue (and resolution) has been captured. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** I always prefer to leave other people some time (like some days) to make comments but if there will be no more comments I'll change "recipe-summary" to "summary" as defined in hCalender/RFC2445 durinng the next week. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*# '''preparation-time could re-use duration instead''' - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from [[hCalendar]] rather than introducing a new property name.
*#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
*#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
*#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** If that's possible than it's okay with me to reuse "duration" with the mentioned syntactic differences. But I'm not sure if it helps usability to overload properties in such a way. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#** The observation that preparation-time uses a nested "note" subproperty may actually reveal a problem with that approach itself, that is, perhaps instead of "preparation-time" with "value" and "note" subproperties, it may be better to refactor it as a "preparation" (an act thereof) with "duration" and "note" subproperties. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#*** While semantically correct this would leave us with one more property, since "preparation" on itself, without a "duration"-subelement, wouldn't make sense anymore. The real content that's of interest - the timespan needed - would reside only in the subelement. See [[recipe-issues]] for more discussion on this topic. [[User:ThomasLoertsch|TomLurge]] 15:00, 16 January 2009 (UTC)
*#* Also, if an hRecipe is nested within an hCalendar (e.g. a ''vtodo'' containing an hRecipe within the ''description''), we probably wouldn't want naïve hCalendar parsers using an hRecipe's cooking time as the entire duration of the hCalendar component. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
*#** This is a duplicate of similar issue(s) raised on hAudio and should be tracked there in [[haudio-issues]]. Parser implementation confusion/naïveté is insufficient to justify a corruption/compromise of the format. Data formats far outlast implementations. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*#** I think the example is rather contrieved. I wouldn't expect microformats to handle such complex cases. I also agree with Tantek that a concise format is more important than naïve parsability. [[User:ThomasLoertsch|TomLurge]] 14:00, 20 January 2009 (UTC)
*#* Although there is no such thing as a "duration of a recipe" the semantics are close enough to justify the reuse of "duration" from [[hCalendar]]. But hCalender is just a refactoring of RFC 2445 which demands ISO style durations which are rather un-intuitive and I would be more concerend about implementors turned away by such requirements than by too many properties. RFC 2445 permits multiple duration values "if the property permits" so that should be fine. Result: I don't know... Btw: hCalender needs more love if it's really meant to be reused. "... editor's note: this list is incomplete (an incomplete list is better than no list) and is being currently edited from RFC2445 to here." imho is not good enough, especially not for a 'specification'. And RFC 2445 is not exactly an easy read. [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
*#** Agreed with the issues raised against hCalendar but please note them in [[hcalendar-issues]] for follow-up. Thanks! [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
*# the issue is a little long already, but before i re-edit it and tear it apart into seperate subissues, i'd like to share what i think could become the draft 0.2. I replaced "recipe-title" with the new "name" (which is defined in a way to facilitate re-use and make the distinction to "fn" clear), replaced "recipe-summary" with "summary", replaced "num" and "unit" from the umfinished 'measure' with "type" and "value" from 'hCard' (i only recently discovered them...), replaced "method" (wihch is already used by [[hCalendar]] with "instructions" (see discussion at the issue "method" below), replaced "preparation-time" with "duration", deleted two "note"s for brevity, marked "summary", "nutrition", "author", "published" and "photo" as 'experimental' (meaning, that they may be removed from future drafts or the final specification, depending on experience and feedback from implementations) :
*# '''hrecipe'''. Proposal for Draft 0.2
*#** '''name''' required. text. [ comment for re-use: only for objects. use "fn" for persons and institutions. ]
*#** '''ingredient''' required. 1 or more. text with optional valid (x)HTML markup.
*#*** '''value''' and '''type'''. optional. re-used from [[hCard]].
*#** '''yield'''. optional. text.
*#** '''instructions'''. optional. text with optional valid (x)HTML markup.
*#** '''duration'''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
*#** '''''summary'''''. optional. text. re-used from [[hCalendar]]. [ ''experimental'' ]
*#** '''''nutrition'''''. optional. 1 or more. [ ''experimental'' ].
*#*** '''''value''''' and '''''type'''''. optional. re-used from [[hCard]]. [ ''experimental'' ].
*#** '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]]. [ ''experimental'' ].
*#** '''''published'''''. optional. re-used from [[hAtom]]. [ ''experimental'' ].
*#** '''''photo'''''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [ ''experimental'' ].
Please comment! [[User:ThomasLoertsch|TomLurge]] 12:47, 22 January 2009 (UTC)
</div>

</div>
<div class="vevent">
* {{OpenIssue}} '''method''' 2008-01-17 raised by [[User:Yde|Yde]]
<div class="description">
*# Would it make sense to [[reuse]] [[hreview|hReview's]] "description" instead of hRecipe's "method" or is this stretching the semantics too far?
*#* I just discovered that hCalender uses "method", and with totally different semantics. So I guess we MUST change it. I'm not very happy with "description" though - that's a very unspecific term. Maybe "instructions", or "steps", or "preparation" , or "procedure"? They are all 'available'. I like "instructions" most, but since I'm not a native speaker I'm hesitant. Maybe the semantics are too different? Maybe "preparation" is better since we already almost have it (or had it - see the discussion about "preparation-time" -> "duration" above)? [[User:ThomasLoertsch|TomLurge]] 12:24, 21 January 2009 (UTC)
</div>
</div>

== resolved issues ==
<div class="vevent">
* {{ResolvedIssue}} 2008-12-27 raised by [[User:Tantek|Tantek Çelik]]
<div class="description">
*# '''author is re-used from hAtom not hCard'''. minor issue. the "author" property is actually re-used from [[hAtom]] rather than hCard - hCard has no such property.
*#* Yikes! Corrected... [[User:ThomasLoertsch|TomLurge]] 17:52, 6 January 2009 (UTC)
</div>
</div>

== closed issues ==
* none currently

===template===
{{issues-format}}

== related pages ==
* [[hRecipe]]
* [[hrecipe-feedback|hRecipe feedback]] for general feedback on hRecipe.
* [[recipe]] microformat effort development
* [[recipe-issues]] past issues raised and resolved during [[recipe-brainstorming]] towards the development of hRecipe.

hrecipe-issues

2009-01-17T10:07:36Z

Yde: /* issues */

hrecipe-issues

2009-01-16T23:33:34Z

Yde: /* issues */ Reuse "description" instead of "method"?

hrecipe-issues

2009-01-16T23:03:36Z

Yde: /* issues */ Added comment about "recipe-title"/"fn"

recipe-brainstorming

2008-10-18T09:50:01Z

Yde: /* Calories */

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

<div id="Format-In-Progress">
==format-in-progress - september 2007==
</div>
This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. (see [[ISO-31-1]] duration brainstorming)
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

'''Title''': The title of the recipe.
* The element is identified by class name <code>recipe-title</code>.
* A Recipe {{must}} have a <code>recipe-title</code>

'''Summary''': The summary provides a short introduction or an accompanying statement about the recipe.
* The element is identified by class name <code>recipe-summary</code>.
* A Recipe {{may}} have a <code>recipe-summary</code>.

'''Author''': Author the person who authored the recipe.
* The element is identified by class name <code>author</code>.
* A Recipe {{may}} include an <code>author</code>.
* The contents of the element {{must}} include a valid [[hCard]].

'''Date published''': The date the recipe was published.
* The element is identified by the class name <code>published</code>.
* A Recipe {{may}} include a <code>published</code> date.
* {{should}} (?) use the [[datetime-design-pattern]] to encode the published datetime.

'''Photo''': Accompanying image.
* The element is identified by the class name <code>photo</code>.
* A Recipe {{may}} include one or more photo elements.
* The element {{should}} use an <code><img></code> element.
* The element {{may}} use any other element that contains a URL, such as <code><a></code> or <code><object></code>, but it is not recommended.

'''Ingredient''': Describes an ingredient used in the recipe.
* The element is identified by the class name <code>ingredient</code>.
* A Recipe {{must}} have one or more <code>ingredient</code>s.
* The element {{must}} include the field item.
* The element {{may}} include <code>quantity</code>, <code>note</code> and/or <code>optionality</code>.

'''Quantity''': The quantity of an ingredient needed for the recipe.
* The element is identified by the class name <code>quantity</code>.
* An ingredient {{may}} specify the <code>quantity</code>.

'''Item''': Specifies the name of the ingredient.
* The element is identified by the class name <code>item</code>.
* An ingredient {{must}} specify the <code>item</code>.

'''Note''': A note concerning one of the ingredients.
* The element is identified by the class name <code>note</code>.
* An ingredient {{may}} include a <code>note</code>.

'''Optionality''': States that an ingredient is optional to the recipe.
* The element is identified by the class name <code>optionality</code>.
* The <code>optionality</code> of an <code>ingredient</code> {{may}} be specified.
* The absence of the element implies that the ingredient is required.

'''Method''': The method of the recipe.
* The element is identified by the class name <code>method</code>.
* A Recipe {{must}} include a <code>method</code>.
* 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 <code>yield</code>.
* A Recipe {{may}} include a <code>yield</code>.

<div id="Format-In-Progress-10-2008">
==format-in-progress - #2 - october 2008==
</div>
This second Format-In-Progress reflects the discussions following the first one from september 2007 (see above). It's not an entirely new format but rather an evolution and about 95% the same as the first one. Most important changes are the adition of a <code>nutrition</code> element , a <code>preparation-time-note</code> element and the optionality of <code>method</code>. To improve readability also parts that haven't changed are repeated, while changes are marked with '''<#2''' and commented.
Please note again 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 [[User:ThomasLoertsch|ThomasLoertsch]] 15:29, 15. Oct 2008 (CET)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** '''<#2''' deleted Optionality
* Method. <code>method</code>. optional. text with optional valid HTML markup. '''<#2''' changed to optional
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. 1 or more, optional. (see [[ISO-31-1]] duration brainstorming) '''<#2''' changed to optionally multiple instances
** Preparation time note. <code>preparation-time-note</code>. optional. text '''<#2''' added
* Tags. optional. [[rel-tag]].
* Nutrition<code>nutrition</code>. optional. Joule [[measure] '''<#2''' added, see Field Details below for a longer version
* License. optional. [[rel-license]].

===Field Details===

'''Title''': The title of the recipe.
* The element is identified by class name <code>recipe-title</code>.
* A Recipe {{must}} have a <code>recipe-title</code>

'''Summary''': The summary provides a short introduction or an accompanying statement about the recipe.
* The element is identified by class name <code>recipe-summary</code>.
* A Recipe {{may}} have a <code>recipe-summary</code>.

'''Author''': Author the person who authored the recipe.
* The element is identified by class name <code>author</code>.
* A Recipe {{may}} include an <code>author</code>.
* The contents of the element {{must}} include a valid [[hCard]].

'''Date published''': The date the recipe was published.
* The element is identified by the class name <code>published</code>.
* A Recipe {{may}} include a <code>published</code> date.
* {{should}} (?) use the [[datetime-design-pattern]] to encode the published datetime.

'''Photo''': Accompanying image.
* The element is identified by the class name <code>photo</code>.
* A Recipe {{may}} include one or more photo elements.
* The element {{should}} use an <code><img></code> element.
* The element {{may}} use any other element that contains a URL, such as <code><a></code> or <code><object></code>, but it is not recommended.

'''Ingredient''': Describes an ingredient used in the recipe.
* The element is identified by the class name <code>ingredient</code>.
* A Recipe {{must}} have one or more <code>ingredient</code>s.
* The element {{must}} include the <code>field</code> item.
* The element {{may}} include <code>quantity</code> and/or <code>note</code>.

'''Quantity''': The quantity of an ingredient needed for the recipe.
* The element is identified by the class name <code>quantity</code>.
* An ingredient {{may}} specify the <code>quantity</code>.

'''Item''': Specifies the name of the ingredient.
* The element is identified by the class name <code>item</code>.
* An ingredient {{must}} specify the <code>item</code>.

'''Note''': A note concerning one of the ingredients.
* The element is identified by the class name <code>note</code>.
* An ingredient {{may}} include a <code>note</code>.
* '''<#2''' '''Optionality''' has been deleted since it's rarely needed and can be stated within a <code>note</code>

'''Method''': The method of the recipe.
* The element is identified by the class name <code>method</code>.
* A Recipe {{may}} include a <code>method</code>.
* The field {{may}} include valid HTML markup (e.g. paragraphs).
* '''<#2''' <code>method</code> is now optional since there are recipes like salads or shakes that don't need a method

'''Yield''': Specifies the quantity produced by the recipe.
* The element is identified by the class name <code>yield</code>.
* A Recipe {{may}} include a <code>yield</code>.

'''Preparation Time''': The time it takes to prepare the meal described by the recipe.
* The element is identified by the class name <code>preparation-time</code>.
* A Recipe {{may}} include one or more <code>preparation-time</code>s.
* '''<#2''' Since some recipes need not only time for preparation, but also considerable time for e.g. boiling, waiting for the dough to rise etc, this element may be used multiple times.

'''Preparation Time Note''': '''<#2''' added. Specifies the purpose of a Preparation Time .
* The element is identified by the class name <code>preparation-time-note</code>.
* A Preparation Time {{may}} include a <code>preparation-time-note</code>.
* An optional note may be added to each of multiple intervals to specify their respective purpose.

'''Nutrition''': '''<#2''' added to optionally provide nutritional information.
* The element is identified by class name <code>nutrition</code>.
* A Recipe {{may}} include a <code>nutrition</code> element.
* This simple version would just add Joules since this is the most used and asked for information.
* 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.
** Nutrition<code>nutrition</code>. optional
*** Energy. <code>energy</code>. optional. Joule [[measure]]
*** Fat. <code>fat</code>. optional. gram [[measure]]
*** Protein. <code>protein</code>. optional. gram [[measure]]
*** Carbohydrates. <code>carbohydrates</code>. optional. gram [[measure]]
*** Dietary fiber. <code>dietary fiber</code>. optional. gram [[measure]]

===Example===

<pre><nowiki><div class="hrecipe">
Pommes Frites
Pommes frites come from the outer space. They are served hot. This recipe is only an example. Don't try this at home!
Thomas Loertsch
Published <abbr class="published" title="2008-10-14T10:05:37-01:00">14. Oct 2008</abbr>
<img src="/img/pommes.png" class="photo" width="100" height="100" alt="Pommes Frites"/>


500
gramme

potatoes,
hard cooking.

<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>
</ul>
Enough for 12 children.
Preparation time is approximately 1 hour 30 minutes.
Add 5 minutes for preparing the Ketchup.
This recipe is easy and delicious.
Pommes Frites have more than 1000 Joule
This recipe is licensed under <a href="http://creativecommons.org/licenses/by/2.0/" rel="license">CC by 2.0</a>.
</div>
</nowiki></pre>

==brainstorming==
===RecipeML-based Brainstorm===
Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

===Cookcamp brainstorming===
At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:
[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|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]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul></nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|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. --[[User:ThomasLoertsch|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. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occasions - what occasions are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|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? [[User:Lee Jordan|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:
<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>
or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):
<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>
: [[User:AndyMabbett|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? --[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)
** -1. Makes no sense to me either --[[User:ThomasLoertsch|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 [[recipe-examples#Menus|menu examples]]. [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

===Calories===
per serving. May be part of the [[measure]] 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. Allrecipes.com 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 <code>nutrition</code> and subelements <code>calories</code>("mandatory") in Joule,<code>fat</code>("optional"), <code>protein</code>("optional"), <code>carbohydrates</code>("optional"), and <code>dietary fiber</code>("optional"), those all in grams. --[[User:ThomasLoertsch|ThomasLoertsch]] 15:16, 01 Oct 2008 (CET), modified 09.Oct 2008 and 13.Oct 2008
** +1 for a <code>nutrition</code> element. However, I would like to change the subelement <code>calories</code> to <code>energy</code>, as that would allow using either calories or joules (using hMeausere) and it feels weird to state joule in an element called calories. --[[User:Yde|Yde]] 05:57, 11 Oct 2008 (PDT)
** I felt the same and <code>energy</code> 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 [[measure#unit:_The_Unit_of_Measurement|<code>unit</code> 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. [[User:TobyInk|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. --[[User:Yde|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 <code>nutrition</code> element, ''optional'', without subelements (and with hMeasure Joule)? I'm still undecided myself. [[User:ThomasLoertsch|ThomasLoertsch]] 12:02, 13.Oct 2008 (CET)

===Note===
The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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. <code>note</code> 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. --[[User:ThomasLoertsch|ThomasLoertsch]] 15:26, 01 Oct 2008 (CET)

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

===Method===
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. [[User:TobyInk|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. --[[User:ThomasLoertsch|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. --[[User:Yde|Yde]] 06:17, 11 Oct 2008 (PDT)
* I think there's no technical way to prevent misuse (and no other way either ;-). --[[User:ThomasLoertsch|ThomasLoertsch]] 12:52, 13.Oct 2008 (CET)

===Preparation Time===
Make <code>preparation-time</code> plural and add an optional <code>preparation-time-note</code> element inline to preparation time
* <code>preparation-time</code> (optional, plural)
** <code>preparation-time-note</code> (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 <code>preparation-time</code> to be used more than once per recipe and adding an optional <code>note</code> 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. --[[User:ThomasLoertsch|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? --[[User:Yde|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. [[User:ThomasLoertsch|ThomasLoertsch]] 12:25, 13 Oct 2008 (CET)

===Quantity===
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)
<code>note</code> 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. --[[User:ThomasLoertsch|ThomasLoertsch]] 15:45, 01 Oct 2008 (CET)

=== Proposed Optimisations ===

====Item====
Can we have this optimisation?... if no "item" is found, the entire ingredient is taken to be the item. [[User:TobyInk|TobyInk]]

Example:
<pre><nowiki>salt</nowiki></pre>
is a shorthand for:
<pre><nowiki>salt</nowiki></pre>
* +1. That and the Proposed Ingredient List Optimisation seem to be very pragmatic proposals. --[[User:Yde|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? --[[User:ThomasLoertsch|ThomasLoertsch]] 15:07, 01 Oct 2008 (CET)

====Ingredient List====

[[User:TobyInk|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.

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

is a shorthand for:

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

* I agree. This would save a lot of space, especially combined with the proposed hmeasure [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)
* Do we have <code>ingredients</code> (plural) as an element? Doesn't that open a whole can of list-issues? --[[User:ThomasLoertsch|ThomasLoertsch]] 15:37, 01 Oct 2008 (CET)

====Ingredient Item/Quantity====

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, item) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

==== Alternative Ingredient Item/Quantity Optimisation ====

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

==issues==
Issues have been moved to a seperate [[recipe-issues|recipe-issues ]] page.

==implementations==
===Cognition===
As of September 2008, [http://buzzword.org.uk/cognition/ Cognition] has experimental support for this format. ([http://buzzword.org.uk/cognition/uf-plus.html#hrecipe Details of support].) Recipes may be exported in [[recipe-formats#RecipeBook_XML|RecipeBook XML]] format or RDF.

== related pages ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]
* [[recipe-issues]]

recipe-brainstorming

2008-10-11T15:15:20Z

Yde: /* Proposed Optimisations */ Canged "name" to "item"

recipe-brainstorming

2008-10-11T13:50:00Z

Yde: /* Proposed Optimisations */

recipe-brainstorming

2008-10-11T13:37:59Z

Yde: /* Proposed Optimisations */ Joined two identical proposals

recipe-brainstorming

2008-10-11T13:32:45Z

Yde: /* Proposed Ingredient Name Optimisation */

recipe-brainstorming

2008-10-11T13:25:43Z

Yde: /* Preparation Time */

recipe-brainstorming

2008-10-11T13:17:59Z

Yde: /* Method */

recipe-brainstorming

2008-10-11T12:57:46Z

Yde: /* Calories */

recipe-brainstorming

2008-10-11T12:34:21Z

Yde: /* Additional Suggestions */ Removed irrelevant suggestion about multiple items per ingredient to avoid clutter

recipe-brainstorming

2008-07-16T12:19:12Z

Yde:

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

'''Title''': The title of the recipe.
* The element is identified by class name <code>recipe-title</code>.
* A Recipe {{must}} have a <code>recipe-title</code>

'''Summary''': The summary provides a short introduction or an accompanying statement about the recipe.
* The element is identified by class name <code>recipe-summary</code>.
* A Recipe {{may}} have a <code>recipe-summary</code>.

'''Author''': Author the person who authored the recipe.
* The element is identified by class name <code>author</code>.
* A Recipe {{may}} include an <code>author</code>.
* The contents of the element {{must}} include a valid [[hCard]].

'''Date published''': The date the recipe was published.
* The element is identified by the class name <code>published</code>.
* A Recipe {{may}} include a <code>published</code> date.
* {{should}} (?) use the [[datetime-design-pattern]] to encode the published datetime.

'''Photo''': Accompanying image.
* The element is identified by the class name <code>photo</code>.
* A Recipe {{may}} include one or more photo elements.
* The element {{should}} use an <code><img></code> element.
* The element {{may}} use any other element that contains a URL, such as <code><a></code> or <code><object></code>, but it is not recommended.

'''Ingredient''': Describes an ingredient used in the recipe.
* The element is identified by the class name <code>ingredient</code>.
* A Recipe {{must}} have one or more <code>ingredient</code>s.
* The element {{must}} include the field item.
* The element {{may}} include <code>quantity</code>, <code>note</code> and/or <code>optionality</code>.

{{OpenIssue}} Can we have this optimisation?... if no "item" is found, the entire ingredient is taken to be the item. [[User:TobyInk|TobyInk]]
* +1. That and [[recipe-brainstorming#Proposed Ingredient List Optimisation|this]] one seems to be very pragmatic proposals. --[[User:Yde|Yde]] 14:40, 14 Jul 2008 (PDT)

'''Quantity''': The quantity of an ingredient needed for the recipe.
* The element is identified by the class name <code>quantity</code>.
* An ingredient {{may}} specify the <code>quantity</code>.

'''Item''': Specifies the name of the ingredient.
* The element is identified by the class name <code>item</code>.
* An ingredient {{must}} specify the <code>item</code>.

'''Note''': A note concerning one of the ingredients.
* The element is identified by the class name <code>note</code>.
* An ingredient {{may}} include a <code>note</code>.

'''Optionality''': States that an ingredient is optional to the recipe.
* The element is identified by the class name <code>optionality</code>.
* The <code>optionality</code> of an <code>ingredient</code> {{may}} be specified.
* The absence of the element implies that the ingredient is required.

'''Method''': The method of the recipe.
* The element is identified by the class name <code>method</code>.
* A Recipe {{must}} include a <code>method</code>.
* The field {{may}} include valid HTML markup (e.g. paragraphs).
{{OpenIssue}} 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. [[User:TobyInk|TobyInk]] 02:53, 15 Jul 2008 (PDT)
* e.g. salad, sandwich and smoothie recipes don't often require a method to be useful.

'''Yield''': Specifies the quantity produced by the recipe.
* The element is identified by the class name <code>yield</code>.
* A Recipe {{may}} include a <code>yield</code>.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Multiple Items per Ingredient==

We need a way to mark-up more than one item per ingredient. This is useful when:

* you need to mark-up more than one <code>item</code> in an <code>ingredient</code> e.g. "salt and pepper".
* you need to mark-up multiple options for an <code>ingredient</code> e.g. "cream or whipping cream".

The first problem could be solved by simply making the two items into two ingredients like this:

<pre><nowiki>salt and pepper</nowiki></pre>

But in a list it would be inconvinient and not very aesthetically pleasing:

<pre><nowiki>
<li class="ingredient">...</li>
<li>salt and pepper</li>
<li class="ingredient">...</li>
</nowiki></pre>

Could we just allow more than one <code>item</code> per <code>ingredient</code>?

For the second problem there is currently no good workaround. There is ''no way to mark-up "or"''. Possible solutions:

* We could reuse the <code>optional</code> property:
<pre><nowiki>Cream or whipping cream</nowiki></pre>

* If this conflicts with other uses of the <code>optional</code> property we might invent another class name for this functionality (<code>option</code>?) but personally I like to keep the scema to a minimum.

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-15T08:25:42Z

Yde: /* Field Details */ More field details added

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

'''Title''': The title of the recipe.
* The element is identified by class name <code>recipe-title</code>.
* A Recipe {{must}} have a <code>recipe-title</code>

'''Summary''': The summary provides a short introduction or an accompanying statement about the recipe.
* The element is identified by class name <code>recipe-summary</code>.
* A Recipe {{may}} have a <code>recipe-summary</code>.

'''Author''': Author the person who authored the recipe.
* The element is identified by class name <code>author</code>.
* A Recipe {{may}} include an <code>author</code>.
* The contents of the element {{must}} include a valid [[hCard]].

'''Date published''': The date the recipe was published.
* The element is identified by the class name <code>published</code>.
* A Recipe {{may}} include a <code>published</code> date.
* {{should}} (?) use the [[datetime-design-pattern]] to encode the published datetime.

'''Photo''': Accompanying image.
* The element is identified by the class name <code>photo</code>.
* A Recipe {{may}} include one or more photo elements.
* The element {{should}} use an <code><img></code> element.
* The element {{may}} use any other element that contains a URL, such as <code><a></code> or <code><object></code>, but it is not recommended.

'''Ingredient''': Describes an ingredient used in the recipe.
* The element is identified by the class name <code>ingredient</code>.
* A Recipe {{must}} have one or more <code>ingredient</code>s.
* The element {{must}} include the field item.
* The element {{may}} include <code>quantity</code>, <code>note</code> and/or <code>optionality</code>.

{{OpenIssue}} Can we have this optimisation?... if no "item" is found, the entire ingredient is taken to be the item.
* +1. That and [[recipe-brainstorming#Proposed Ingredient List Optimisation|this]] one seems to be very pragmatic proposals. --[[User:Yde|Yde]] 14:40, 14 Jul 2008 (PDT)

'''Quantity''': The quantity of an ingredient needed for the recipe.
* The element is identified by the class name <code>quantity</code>.
* An ingredient {{may}} specify the <code>quantity</code>.

'''Item''': Specifies the name of the ingredient.
* The element is identified by the class name <code>item</code>.
* An ingredient {{must}} specify the <code>item</code>.

'''Note''': A note concerning one of the ingredients.
* The element is identified by the class name <code>note</code>.
* An ingredient {{may}} include a <code>note</code>.

'''Optionality''': States that an ingredient is optional to the recipe.
* The element is identified by the class name <code>optionality</code>.
* The <code>optionality</code> of an <code>ingredient</code> {{may}} be specified.
* The absence of the element implies that the ingredient is required.

'''Method''': The method of the recipe.
* The element is identified by the class name <code>method</code>.
* A Recipe {{must}} include a <code>method</code>.
* 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 <code>yield</code>.
* A Recipe {{may}} include a <code>yield</code>.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T21:40:59Z

Yde: /* Field Details */

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

'''Title''': The title of the recipe.
* The element is identified by class name <code>recipe-title</code>.
* A Recipe {{must}} have a <code>recipe-title</code>

'''Summary''': The summary provides a short introduction or an accompanying statement about the recipe.
* The element is identified by class name <code>recipe-summary</code>.
* A Recipe {{may}} have a <code>recipe-summary</code>.

'''Author''': Author the person who authored the recipe.
* The element is identified by class name <code>author</code>.
* A Recipe {{may}} include an <code>author</code>.
* The contents of the element {{must}} include a valid [[hCard]].

'''Photo''': Accompanying image.
* The element is identified by the class name <code>photo</code>.
* A Recipe {{may}} include one or more photo elements.
* The element {{should}} use an <code><img></code> element.
* The element {{may}} use any other element that contains a URL, such as <code><a></code> or <code><object></code>, but it is not recommended.

'''Ingredient''': Describes an ingredient used in the recipe.
* The element is identified by the class name <code>ingredient</code>.
* A Recipe {{must}} have one or more <code>ingredient</code>s.
* The element {{must}} include the field item.
* The element {{may}} include <code>quantity</code>, <code>note</code> and/or <code>optionality</code>.

{{OpenIssue}} Can we have this optimisation?... if no "item" is found, the entire ingredient is taken to be the item.
* +1. That and [[recipe-brainstorming#Proposed Ingredient List Optimisation|this]] one seems to be very pragmatic proposals. --[[User:Yde|Yde]] 14:40, 14 Jul 2008 (PDT)

'''Optionality''': States that an ingredient is optional to the recipe.
* The element is identified by the class name <code>optionality</code>.
* The <code>optionality</code> of an <code>ingredient</code> {{may}} be specified.
* The absence of the element implies that the ingredient is required.

'''Method''': The method of the recipe.
* The element is identified by the class name <code>method</code>.
* A Recipe {{must}} include a <code>method</code>.
* 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 <code>yield</code>.
* A Recipe {{may}} include a <code>yield</code>.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T21:34:57Z

Yde: /* Field Details */ Changed formatting to be more like haudio. More clear this way.

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

'''Title''': The title of the recipe.
* The element is identified by class name <code>recipe-title</code>.
* A Recipe {{must}} have a <code>recipe-title</code>

'''Summary''': The summary provides a short introduction or an accompanying statement about the recipe.
* The element is identified by class name <code>recipe-summary</code>.
* A Recipe {{may}} have a <code>recipe-summary</code>.

'''Author''': Author the person who authored the recipe.
* The element is identified by class name <code>author</code>.
* A Recipe {{may}} include an <code>author</code>.
* The contents of the element {{must}} include a valid [[hCard]].

'''Photo''': Accompanying image.
* The element is identified by the class name <code>photo</code>.
* A Recipe {{may}} include one or more photo elements.
* The element {{should}} use an <code><img></code> element.
* The element {{may}} use any other element that contains a URL, such as <code><a></code> or <code><object></code>, but it is not recommended.

'''Ingredient''': Describes an ingredient used in the recipe.
* The element is identified by the class name <code>ingredient</code>.
* A Recipe {{must}} have one or more <code>ingredient</code>s.
* The element {{must}} include the field item.
* The element {{may}} include <code>quantity</code>, <code>note</code> and/or <code>optionality</code>.

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

'''Optionality''': States that an ingredient is optional to the recipe.
* The element is identified by the class name <code>optionality</code>.
* The <code>optionality</code> of an <code>ingredient</code> {{may}} be specified.
* The absence of the element implies that the ingredient is required.

'''Method''': The method of the recipe.
* The element is identified by the class name <code>method</code>.
* A Recipe {{must}} include a <code>method</code>.
* 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 <code>yield</code>.
* A Recipe {{may}} include a <code>yield</code>.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T20:33:37Z

Yde: /* Field Details */

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

Title: This required field serves as the title of the recipe.

Summary: This optional field provides a short introduction, accompanying statement about the recipe.

Author: This optional field specifies the person who authored the recipe. If the author is specified, an [[hCard]] representing the author {{must}} be provided.

Photo: Accompanying image. If an <code><a></code> element is used, the href="..." attribute provides the property value. If an <code><img></code> element is used, the src="..." attribute provides the property value.

Ingredient: One or more ingredients required. An ingredient {{must}} include the field item and {{may}} include one or more of the following fields: quantity, note and/or optionality.

Method: This required field contains the method of the recipe. The field may include valid HTML markup (e.g. paragraphs).

Optionality: This optional field states that an ingredient is optional to the recipe. This field's absence implies that the ingredient is required.

Yield: This optional field specifies the quantity produced by the recipe.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T15:29:03Z

Yde: /* Field Details */

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

Title: This required field serves as the title of the recipe.

Summary: This optional field provides a short introduction, accompanying statement about the recipe.

Author: This optional field specifies the person who authored the recipe. If the author is specified, an [[hCard]] representing the author {{must}} be provided.

Photo: Accompanying image. If an <code><a></code> element is used, the href="..." attribute provides the property value. If an <code><img></code> element is used, the src="..." attribute provides the property value.

Method: This required field contains the method of the recipe. The field may include valid HTML markup (e.g. paragraphs).

Optionality: This optional field states that an ingredient is optional to the recipe. This field's absence implies that the ingredient is required.

Yield: This optional field specifies the quantity produced by the recipe.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T14:39:12Z

Yde: /* Measure */ Deleted two irrelevant issues i had raised

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

Summary: A short introduction, accompanying statement about the recipe.

Author: An [[hCard]] for the author of the recipe.

Photo: Accompanying image.

Method: The block of text containing the method of the recipe.

Optionality: States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

Yield: Quantity produced by this recipe.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T14:19:41Z

Yde: /* Known Issues */ added link to another thread

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

Summary: A short introduction, accompanying statement about the recipe.

Author: An [[hCard]] for the author of the recipe.

Photo: Accompanying image.

Method: The block of text containing the method of the recipe.

Optionality: States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

Yield: Quantity produced by this recipe.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T14:15:47Z

Yde: /* Known Issues */ Updated the measure discussion to reflect what seems to be the consensus on the mailing list.

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

Summary: A short introduction, accompanying statement about the recipe.

Author: An [[hCard]] for the author of the recipe.

Photo: Accompanying image.

Method: The block of text containing the method of the recipe.

Optionality: States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

Yield: Quantity produced by this recipe.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T11:09:12Z

Yde: /* Known Issues */ Fixed line break

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

Summary: A short introduction, accompanying statement about the recipe.

Author: An [[hCard]] for the author of the recipe.

Photo: Accompanying image.

Method: The block of text containing the method of the recipe.

Optionality: States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

Yield: Quantity produced by this recipe.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.

{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T10:58:36Z

Yde: /* Field Details */

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

Summary: A short introduction, accompanying statement about the recipe.

Author: An [[hCard]] for the author of the recipe.

Photo: Accompanying image.

Method: The block of text containing the method of the recipe.

Optionality: States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

Yield: Quantity produced by this recipe.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T10:57:01Z

Yde: /* Format-In-Progress */ Created incomplete section for Field Details

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Field Details===

Summary: A short introduction, accompanying statement about the recipe.

Author: An [[hCard]] for the author of the recipe.

Photo: Accompanying image.

Method: The block of text containing the method of the recipe.

Optionality: States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-14T10:48:06Z

Yde: Merged section Schema Proposal with Format-In-Progress whose purpose is "to be edited to reflect the discussion that occurs on the microformats-new list" which was also the purpose of Scema Proposal.

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* Title. <code>recipe-title</code>. required. text.
* Summary. <code>recipe-summary</code>. optional. text.
* Author. <code>author</code>. optional. [[hcard]].
* Date published. <code>published</code>. optional. [[datetime-design-pattern]].
* Photo(s). <code>photo</code>. optional. img or url.
* Ingredient(s). <code>ingredient</code>. 1 or more required.
** Quantity. <code>quantity</code>. optional. text, optionally [[measure]].
** Item. <code>item</code>. required. text.
** Note. <code>note</code>. optional. text.
** Optionality. <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* Method. <code>method</code>. required. text with optional valid HTML markup.
* Yield. <code>yield</code>. optional. text.
* Preparation time. <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* Tags. optional. [[rel-tag]].
* License. optional. [[rel-license]].

===Suggested fields for inclusion===

* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Calories – per serving. May be part of the [[measure]] microformat in future.

===Known Issues===

This section reflects the discussion that occurs on the microformats-new list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here] and [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here]).

{{OpenIssue}} Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ClosedIssue}} We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{OpenIssue}} The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
* We might want to [[principles|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".

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-10T14:56:25Z

Yde: /* Schema proposal */ changed 'entry-title' and 'entry-summary' to 'recipe-title' and 'recipe-summary'

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

''Note, this format-in-progress is no-longer being actively developed. The current recipe format work is under [[recipe-brainstorming#Schema_proposal|Schema Proposal]]

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>recipe-title</code>. required. text.
* '''Summary''': <code>recipe-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text with optional valid HTML markup.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Discussion ===
* <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
** <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
** <code>recipe-title</code> and <code>recipe-summary</code> suggested.
** '''Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.'''
* The 'photo' property should be usable for elements containing the element <code><img></code>.
** This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
* We need a way to markup alternative ingredients.
** This is not entirely straight-forward. We should put this off for a future revision.
* The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
** We might want to [[principles|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".

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-07-10T14:32:03Z

Yde: /* Schema proposal */ added option of valid HTML markup in 'method' (the same way 'description' works in hReview)

<h1>Recipe Brainstorming</h1>

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is 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 documentation was produced by [[User:BenWard|Ben Ward]] and [[User:Phae|Frances Berriman]].

''Note, this format-in-progress is no-longer being actively developed. The current recipe format work is under [[recipe-brainstorming#Schema_proposal|Schema Proposal]]

; Editor
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text with optional valid HTML markup.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Discussion ===
* <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
** <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
** <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* The 'photo' property should be usable for elements containing the element <code><img></code>.
** This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
* We need a way to markup alternative ingredients.
** This is not entirely straight-forward. We should put this off for a future revision.
* The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
** We might want to [[principles|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".

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-26T21:58:26Z

Yde: /* Discussion */ added concern about the 'note' property

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Discussion ===
* <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
** <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
** <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* The 'photo' property should be usable for elements containing the element <code><img></code>.
** This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
* We need a way to markup alternative ingredients.
** This is not entirely straight-forward. We should put this off for a future revision.
* The 'note' property is only useful in some [http://microformats.org/discuss/mail/microformats-new/2008-June/001635.html rare cases] and might not fit the 80-20 rule.
** We might want to [[principles|start as simple as possible]] and leave this out for a future revision.

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-24T20:41:08Z

Yde: /* Discussion */ added discussion about alternative ingredients

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Discussion ===
* <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
** <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
** <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* The 'photo' property should be usable for elements containing the element <code><img></code>.
** This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
* We need a way to markup alternative ingredients.
** This is not entirely straight-forward. We should put this off for a future revision.

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-24T20:25:04Z

Yde: /* Issues */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
***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. [[User:Quixote|Ben Curtis]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Discussion ===
* <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
** <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
** <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* The 'photo' property should be usable for elements containing the element <code><img></code>.
** This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-12T20:36:11Z

Yde: /* Issues */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Issues ===
{{OpenIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-12T16:38:18Z

Yde: /* Issues */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Issues ===
{{OpenIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]).
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-12T16:34:00Z

Yde: /* Issues */ Trying to avoid list bug

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Issues ===
{{OpenIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-12T15:39:47Z

Yde: /* Schema proposal */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

=== Issues ===
* {{OpenIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
** <code>recipe-title</code> and <code>recipe-summary</code> suggested.

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-12T15:30:36Z

Yde: /* Schema proposal */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])

Class names <code>author</code> and <code>published</code> are taken from [[hAtom]], <code>photo</code> used from [[hCard]] and <code>item</code> from [[measure]].

* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-12T11:50:20Z

Yde: /* Proposed Ingredient Name Optimisation */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

Maybe we should even allow markup like

<pre><nowiki><li class="ingredient">1 tbspsalt</li></nowiki></pre>

which would be parsed as

* ingredient
** quantity: 1 tbsp
** name: salt

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])
* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-examples

2008-06-10T15:59:32Z

Yde: /* Services */ Added Goggle Base

<h1> Recipe Examples </h1>

Per the microformats [[process]] this is an [[examples]] page documenting existing real world examples of actual ''tasty'' recipes published on the Web. Next steps are to research [[recipe-formats]] and then (only ''after'' that), proceed with [[recipe-brainstorming]]. Only URLs to actual recipes please.

'''Please read both [[process]] and [[examples]] before editing this page.'''

__TOC__

== Contributors ==

* [http://tantek.com/ Tantek Çelik]
* [[User:RobertBachmann|Robert Bachmann]]
* [[User:JeffMcNeill|jeffmcneill]]

== Recipe Lists ==
* [http://orens.com/stuff/recipes.html Steve and Aytek's recipes]. Note that they are simply using [[xoxo|XOXO]] for the lists. It doesn't appear that anything more is necessary for a list of recipes.
* [http://www.myvegrecipes.com/category/main-dishes My Veg Recipes]. Also uses [[xoxo|XOXO]] for lists of recipes.
* ...
* ...

== Recipes Examples ==

=== Individuals ===

==== Hamburger ====
[http://en.wikibooks.org/wiki/Cookbook:Hamburger Wikibooks Cookbook:Hamburger]

Composed of
* Summary
** Categories
** Servings
** Time
** Rating
** Energy
** Image
* Recipe
** Description (text)
** Ingredients (required/optional)
** Procedure (OL)
** Suggestions (text)
** Notes, tips and variations (UL)
** Categories

==== Lentil Stew ====
[http://1moon.com/recipes/mercimek.html Neriman’s Mercimek - Yummy Lentils]

* Appears to be a simple BBEdit 5.0 conversion of a plain text file into HTML 3.2
* Uses <code> </code> to delimit sections
* Composed of:
** author of recipe
** title of recipe, with English translation
** top level structure of time/instructions, with ingredients noted as necessary for each step
** serving suggestion(s) (serve with ...)

==== Mocha Brownie Cake ====
[http://orens.com/stuff/recipe_data/mocha_brownie_cake.html Mocha Brownie Cake]

* Composed of
** title of recipe / food item (looks like a heading)
** sequence of larger tasks (separated by subheadings), each of which has
*** list of ingredients (uses <code><ul></code>) for a particular component of the dish
*** preparation instructions for those ingredients
*** OR a instructions for assembling components of the dish
** contributing baker - perhaps someone who has modified the recipe?
** source - citation of where recipe originally came from

==== A Moroccan-ish Casserole ====
[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ Simon Wheatley]

* Structured semantic XHTML based, as well as possible, on hcard/review type principles
* Composed of:
** title
** description
** number of servings (quantity)
** prep time
** cooking time
** approval rating (from hreview)
** ingredients
** preparation steps

May expand to include: variation suggestions

==== Fruit Salad ====

[http://diveintomark.org/archives/2006/06/09/fruit-salad-recipe fruit salad (Mark Pilgrim)]

Extremely detailed instructions.

* Composed of (at least)
** title of recipe
** description
** number of servings (quantity)
** shopping instructions
** ingredients
** ingredients to avoid
** preparation steps
** left-over preservation instructions

==== Perfect Flank Steak ====

[http://www.dvorak.org/blog/?p=6283 John C. "CSS is a series of tubes" Dvorak]

* Composed of
** title of recipe
** description
** ingredients
** preparation steps
** suggested accompaniments

==== Veggie Chicken Enchiladas ====

[http://www.myvegrecipes.com/recipe/chicken-enchiladas Veggie Chicken Enchiladas]
[http://www.myvegrecipes.com/recipe/xml/chicken-enchiladas.xml Veggie Chicken Enchiladas XML]

* Attempts to use XOXO as a recipe microformat
* Composed of
** ingredients
** instructions
** servings
** prep time
** serving suggestions
** cook's tips
** variations
** time saving tips

====Spaghetti primavera====

[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti-primavera]

*Written as prose
*Contains:
** introduction - containing source of original recipe book inspiration
** ingredients (in paragraph, comma separated)
** instructions (paragraph)
** observation (creates a lot of washing up!)

=== Services ===

==== cookingwithbooze.org ====
*[http://cookingwithbooze.org/ Cooking with Booze] is a cookbook and associated free-access website. All the recipes are marked up in a combination of XOXO and microformat:
* Composed of
** title of recipe (as a heading)
** note/introduction
** unordered list of ingredients
** ordered list of instructions
* [http://cookingwithbooze.org/for-geeks#microformats More information about the microformat]
* You can also download the whole recipe list as a dataset for your own experiments, in the form as a tagged XML file as output by InDesign. [http://cookingwithbooze.org/for-geeks#microformats]
* Any questions: [http://shorttermmemoryloss.com http://shorttermmemoryloss.com]

==== allrecipes.com - Sachertorte ====
[http://cake.allrecipes.com/az/Sachertorte.asp Sachertorte (allrecipes.com)]

* Composed of
** title of recipe (as a heading)
** name of the submitter
** description of the food item (e.g: "Elegant chocolate cake.")
** optional photo
** servings count
** sequence of ingredients (uses <code><ul></code>)
** sequence of preperation instructions (uses <code><ol></code>)

==== BBC Food - Marzipanned fruit cake ====

[http://www.bbc.co.uk/food/recipes/database/marzipannedfruitcake_14581.shtml Marzipanned fruit cake] [http://www.bbc.co.uk/food/recipes/ BBC Food Recipes]

* Composed of (all B&BR markup)
** title of recipe
** name of submitter/source
** servings count/quanity
** preparation time
** cooking time
** image
** suitable for vegetarians icon
** description of recipe
** ingredients list
** method steps
** notes

==== cooking.com - Jamaican Chicken Stew Recipe ====
[http://www.cooking.com/recipes/rerecite.asp?No=8196 Jamaican Chicken Stew Recipe (cooking.com)]
* Consists of
** Recipe Title (<code></code><code></code> used for header)
*** Source (Magazine, book, title, etc. with a link.)
*** Serving Size
** Photo area
*** Recipe Email, Save, Print options
*** Photo
** Recipe Ingredients (heading uses <code></code> <code> </code>, each ingredient in separate <code><td></code>, ingredient keywords linked to a glossary)
** Recipe Method (no <code></code> used, uses <code><td></code>, <code></code> and <code> </code>)
*** Copyright reprint info appears at end of prep info.
** Nutrition Facts (<code></code><code></code> used for header)
*** Serving size info repeated
*** Nutritional elements per serving (each item and value are in separate <code><td></code>)

Notes: No meaningful markup used. Recipes use <code><table></code> for all layout/presentation. <code></code>, <code> </code>, and nested <code></code> used throughout. Line images separate sections of recipe.

==== cuzza.com - Chicken Jalfrezi Recipe ====
[http://cuzza.com/recipes/jalfrezi/ Chicken Jalfrezi Recipe (cuzza.com)]
* Consists of
** Recipe Title (<code><h2></code>)
*** Subheading/summary description (<code><h3></code>)
*** Teaser text with photo (<code><div class="teaser"><div class="mainImg"></code>)
** Method steps (each step in a <code><div class="step"></code> with an image and text)
** Number of servings (<code><h5></code>)
** Ingredients list (in a definition list; quantities and units not marked up separately; some ingredients link to an explanatory page)
** "Chef's notes". Explanatory notes offering advice and alternatives.

==== epicurious.com - Moroccan Braised Beef ====
[http://www.epicurious.com/recipes/recipe_views/views/230639 Moroccan Braised Beef (epicurious.com)]
* Composed of
** Recipe Intro Area
*** Photo (uses <code></code>)
*** Recipe Title (uses <code><h1></code>)
*** Quick intro description (No <code></code>)
** Ingredients * (uses <code> </code>)
** Preparation *
*** Preparation instructions (some recipes offer Cooks' notes: - surrounded by *b* tagset, and uses <code> </code> )
*** Serving size
*** Origin (span class = source, magazine title)
*** Copyright info (span class = copyright: publication date and location if available)
** Your notes * (user/visitor may add/submit notes to appear on their printed copy)
** Reviews * (fork ratings, 1-4)

Notes: Images are the secondary headings * (class = hdr) , no sub heading markup. Recipes do not use use <code><li></code> and use <code> </code> instead of <code></code> often.

==== extratasty.com - Cuba Libre ====
[http://www.extratasty.com/recipe/46/cuba_libre Cuba Libre (extratasty.com)]

* Composed of
** title of recipe
** name of the submitter
** sequence of ingredients
** preperation instructions (continuous text)
** Recipe rating (US school grad system)

==== recipesource.com - Cranberry Cherry Relish ====
[http://www.recipesource.com/side-dishes/relishes/00/rec0053.html CRANBERRY CHERRY RELISH (recipesource.com)]
* Consists of
** Exported info (if from mastercook, mealmaster)
** Title (in uppercase)
** Recipe by: (source, author info)
** Serving size: Preparation Time:
** Categories:
** Ingredients ( displayed in columns: Amount : Measure : Ingredient -- Preparation Method )
** Cooking Instructions

Note: Recipe is in text format using <code><pre></code> inside a <code><td></code>.

==== www.cooker.net - Muffins Zucca e Radicchio ====
[http://www.cooker.net/cooker/cooker.nsf/puid/9F1CF8E0983AC24186257286003C2277 Muffins Zucca e Radicchio (cooker.net)]

*Consists of:
**Yield
**Unordered list of ingredients
**Preparations
**Photographs
**Feedback
**Classification (category recipe features in)

==== asianfoodgrocer.com - Asian Rice Salad ====
[http://www.asianfoodgrocer.com/recipes/77439.shtml Asian Rice Salad (AsianFoodGrocer.com)]

*Consists of:
**Title
**Yield
**Blurb
**Ingredients (3 column table)
**Instructions (numbered but not an ordered list)
**Author or Source Credit

b and br markup, no headings. Ingredients displayed in table, one ingredient per row - 3 columns: first for quantity or measurement number, second for measure type if there is one (c, ts, tb, etc.), third column for the ingredient type.

==== Good Living: Sydney Morning Herald - Asparagus and herb frittata ====

[http://www.smh.com.au/news/recipes/asparagus/2007/09/10/1189276601142.html Asparagus and herb frittata (smh.com.au/news/recipes/ Sydney Morning Herald: Recipes)]

Note: An article about Asparagus contains this recipe.

* Article Title (h1 markup)
** Author
** Date
** Article content
*** Recipe Title (h3 markup)
**** Ingredients (1 paragraph, ingredients separated with br markup)
**** Directions (method, p used for steps)
**** Servings (p, b markup)

Measurement units note: This recipe mixes, tbs, cm, ml, and g.

==== Real Cajun Recipes: Chicken Fricassee ====
[http://www.realcajunrecipes.com/recipes/cajun/chicken-fricassee/4.rcr Chicken Fricassee (RealCajunRecipes.com)]

Recipe is formatted with table/nested table

* Title (h3 heading)
** Food Category (not linked)
** Recipe Author
** Author origin (location)
** Date
** Drag and Drop icon for MacGourmet* users
** Ratings (up to 5 stars)
** Ratings link (viewer can rate recipe)
* The top section of the recipe is separated with an hr, rest of recipe in nested table.
** servings
** prep time
** cook time
** ready time
** author note
** Ingredients (appear in two columns, table)
** Directions (paragraph format for steps)

'''Special Note'''*
[http://www.apple.com/downloads/macosx/home_learning/macgourmet.html MacGourmet] is software which allows creation, import (of other recipes and recipe formats), export of recipes, Publishing of recipes to MovableType, Blogger, TypePad, and Blojsom weblogs. Categorization and search features. It would be good to see how these recipes are formatted. MacGourmet - 'iTunes for recipes' and can create/export shopping lists for the recipes (including to PDA, iPod, etc.), Demo available at link. Also see wiki page [[recipe-formats#MacGourmet]]

==== BigOven: Angel Hair with Tomatoes, Basil And Arugula recipe ====

Recipe Example: [http://www.bigoven.com/152986_Angel-Hair-with-Tomatoes,-Basil-And-Arugula_recipe.html Angel Hair with Tomatoes, Basil And Arugula recipe (BigOven)].

[http://bigoven.com/ BigOven] - recipe software application with an online collection of recipes which were submitted from registered site users or published, exported from its software users. Published recipes can be rated online, and additional tags/categories or ingredients can be applied to published recipes. Also see the [[recipe-formats#Big_Oven]] wiki page.

Recipe output for the site uses span tags with id to format or link information. HTML format: ingredients are in table format. Uses br, no p tags.

This is an example recipe format from the site:

* Recipe Title - h1, span id="lblTitle"
** Intro Line - span id="lblSubhead", br
** Ratings - img id="img_rating"
** Photo
** Ingredients - h2, span id="Label1"
*** Individual Ingredients - (2 column table, ingredient keyword is linked, link appended with id=ingredient name.)
** Instructions - h2, span id="Label2"
*** Directions (br, span id="lblInstructions", br) - instructions, nutritional info, author, date included.
** Main ingredient tag - span id="Label7", span id="lblMainIngredient" , link to Main Ingredient)
** ADD tags. Form submit buttons for additional tag categorization (related linking). - id="lblCategoriesLabel"

==== Gopher: Fudge Recipe ====
[gopher://hal3000.cx/0/Recipes/fudge.txt gopher://hal3000.cx/0/Recipes/fudge.txt]

Note: this is '''gopher:''' (may not work in all browsers, will with Firefox)

Format plain text -- formatting line breaks, sometimes dashes for ingredient lists, underlining of title. Whitespace preserved with pre tagset.

Recipe consists of:
* Introductory information
* Recipe Title
** Ingredients
** Instructions

Another Recipe collection on Gopher at the Online Book Initiative:

[gopher://gopher.std.com/11/The%20Online%20Book%20Initiative/Recipes gopher://gopher.std.com/11/The%20Online%20Book%20Initiative/Recipes]

==== DobrePrzepisy.org: Faworki ====
Recipe example: [http://dobreprzepisy.org/przepis/255/faworki.html Faworki (dobreprzepisy.org)]

* Composed of:
** title of recipe (<code><h1></code>)
** food category (links to the directory)
** name of the submitter (links to profile) and date added
** rating (stars, 1-5)
** optional photo
** additional info: (<code><h3> and <ul></code>)
*** difficulty (3 levels: easy | intermediate | difficult)
*** servings count
*** preparation time
*** overall cost
*** suitable for vegetarians icon (added as <code>background-image</code>)
** sequence of ingredients (<code><ul></code>)
** preparation instructions (<code></code>)
** user's comments

==== W3.org Lists Example ====
[http://www.w3.org/TR/html4/struct/lists.html#h-10.1 w3.org]

* Composed of
** <code><dl></code>
*** <code><dt></code> - ingredients heading
*** <code><dd></code>
**** <code><ol></code> and <code><li></code> - ingredients
*** <code><dt></code> - procedure heading
*** <code><dd></code>
**** <code><ul></code> and <code><li></code> - procedure
*** <code><dt></code> - notes heading
*** <code><dd></code> - notes

==== Google Base ====

Composed of:
* Title
* Main ingredient
* Cuisine
* Servings
* Calories
* Cholesterol
* Cooking time
* Course
* Meal type
* Preparation time
* Protein

===Menus===

==== The Crepe Vine ====

See [http://www.thecrepevine.com/menu.html The Crepe Vine].

*Item Name
*Price
*Ingredients/Description

<pre>
APPETIZERS
IMPORTED CHEESE PLATE & BAGUETTE ..........13 
 
TUNA TARTARE ..........8 
fresh tuna with roasted shallot aioli, and lotus chips 
 
BRUSCHETTA ..........8
 
tomato, garlic, basil, chevre, olive oil and balsamic on crostini 
 
STEAK TARTARE .......... 12
 
Horseradish aioli, caramelized shallots, and potato hash 
 
BABY BEET SALAD ..........11
 
candy cane baby beets, sherry vinaigrette and herb goat cheese
</pre>

==== Luigi Ortegas ====

See [http://www.luigiortegas.com/menu/wood_fire_pies.html Luigi Ortegas]

*Item Name
*Price
*Standard Ingredients
*Optional Ingredients
*Ingredient Price

<pre>
<div id="e2" style="position: absolute; left: 212px; top: 500px; width: 596px; height: 39px;">


Cheese Pie ............ 6.99 


Tomato Sauce and Mozzarella Cheese. 


</div>
<div id="e3" style="position: absolute; left: 212px; top: 544px; width: 596px; height: 135px;">


Meat Toppings:


ADD EXTRA $1.00 EACH 


Giant Pepperoni, Sausage, Salami, Beef Meatballs, Canadian Bacon, Mortadella, Real Bacon, Chorizo and Anchovies. 


Veggie Toppings: ADD EXTRA $1.00 EACH 


Sauteed Mushrooms, Sauteed White Onions, Sauteed Green Bell Peppers, Black Olives, Grilled Eggplant, Sun Dried Tomatoes,
Jalapenos, Fresh Basil, Fresh Cilantro, Grilled Zucchinis, Pineapple, Roma Tomatoes and Elephant Garlic.


Cheese:  ADD EXTRA $1.50 EACH 


Mozzarella, Feta, Cheddar, Fresh Mozzarella and Ricotta. 

</pre>

== Next Steps ==
# Add more examples and analysis of their markup and implied schemas
# Research existing [[recipe-formats]] ([http://home.comcast.net/~episoft/ Mealmaster], [http://www.formatdata.com/recipeml/ RecipeML], ...)
# [[recipe-brainstorming]] on a minimal recipe schema that represents the 80/20 of common properties of the examples and reuses terms from existing widely implemented recipe formats.

recipe-brainstorming

2008-06-08T21:16:35Z

Yde: /* Additional Suggestions */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
** Tags could be used for both suitability and category.

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])
* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-06-08T19:58:14Z

Yde: /* Schema proposal */ Changed formatting to make the list more compact and easier to read.

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])
* '''Title''': <code>entry-title</code>. required. text.
* '''Summary''': <code>entry-summary</code>. optional. text.
* '''Author''': <code>author</code>. optional. [[hcard]].
* '''Date published''': <code>published</code>. optional. [[datetime-design-pattern]].
* '''Photo(s)''': <code>photo</code>. optional. img or url.
* '''Ingredient(s)''': <code>ingredient</code>. 1 or more required.
** '''Quantity''': <code>quantity</code>. optional. text, optionally [[measure]].
** '''Item''': <code>item</code>. required. text.
** '''Note''': <code>note</code>. optional. text.
** '''Optionality''': <code>optional</code>. optional. text. Its absence should imply that the ingredient is required.
* '''Method''': <code>method</code>. required. text.
* '''Yield''': <code>yield</code>. optional. text.
* '''Preparation time''': <code>preparation-time</code>. optional. [[datetime-design-pattern]].
* '''Tags''': optional. [[rel-tag]].
* '''License''': optional. [[rel-license]].

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-05-30T16:21:38Z

Yde:

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

==Schema proposal==
Based on the brainstorm and the discussions on the mailing list ([http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html], [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html])
* Title
** <code>entry-title</code>
** required
** text
* Summary
** <code>entry-summary</code>
** optional
** text
* Author
** <code>author</code>
** optional
** [[hcard]]
* Date published
** <code>published</code>
** optional
** [[datetime-design-pattern]]
* Photo(s)
** <code>photo</code>
** optional
** img or url
* Ingredient(s)
** <code>ingredient</code>
** 1 or more required.
** Quantity
*** <code>quantity</code>
*** optional
*** text, optionally [[measure]]
** Item
*** <code>item</code>
*** required
*** text
** Note
*** <code>note</code>
*** optional
*** text
** Optionality
*** <code>optional</code>
*** optional
*** Text. Its absence should imply that the ingredient is required.
* Method
** <code>method</code>
** required
** text
* Yield
** <code>yield</code>
** optional
** text
* Preparation time
** <code>preparation-time</code>
** optional
** [[datetime-design-pattern]]
* Tags
** optional
** [[rel-tag]]
* License
** optional
** [[rel-license]]

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

measure-brainstorming

2008-05-30T16:06:39Z

Yde: /* Issues */

= Measure Microformat Brainstorming =

This page collects ideas on how to use semantic XHTML to represent unambiguously [[measure]]s.

== Guillaume Lebleu ==

Basic example with elementary unit using the abbr pattern and the UNECE code (see [[measure-formats]])

<pre>
5 <abbr class="unit" title="FOT">Feet</abbr>
</pre>

Optional "value" could be useful in some cases, for instance when the value is provided in plain text:

<pre>
<abbr class="value" title="5">Five</abbr> <abbr class="unit" title="FOT">Feet</abbr>
</pre>

==Andy Mabbett==

===Converter Extension===
This Firefox extension may be of interest. Note, though, that it's been criticised for having a "nag" screen: [https://addons.mozilla.org/firefox/2286/ Converter] [[User:AndyMabbett|AndyMabbett]] 15:32, 3 Oct 2006 (PDT)

:This is the author of that extension. I don't want to go much into this, but I just want to clarify this briefly. The part with the nag screen is wrong on two counts: (1) that dialog isn't there anymore, and (2) even if it was there, you only needed to read a paragraph and click a button to make it go away ''forever'' -- but you don't have to take my word for it, install it for yourselves and see. Andy's report is accurate however -- the extension '''''was''''' criticized for that dialog (that's what you get from your free extension's users when you ask for 15 seconds of their time in return for hundreds of hours of your time). --[[User:BogdanStancescu|BogdanStancescu]] 09:35, 9 Oct 2006 (PDT)

===Wikipedia converter===
Wikipedia's [http://en.wikipedia.org/wiki/Template:Convert Convert Template] automatically converts from metric to imperial and vice versa. It's worth noting the measurements it supports.

===Google calculator===
A Google search, e.g. for "0.6 miles" [http://www.google.co.uk/search?q=0.6+miles returns a metric conversion]. See also [http://www.google.co.uk/intl/en/help/calculator.html Google calculator help].

===HTML Entities===
*For squared and cubic values, the HTML entities <code>&sup2;</code> and <code>&sup3;</code> should be borne in mind.

*For temperatures and angels, the HTML entity <code>&deg;</code> exists.

*The following currency entities exist:
**<code>¤</code> - <code>&curren;</code> - currency
**<code>¢</code> - <code>&cent;</code> - cent
**<code>£</code> - <code>&pound;</code> - pound
**<code>¥</code> - <code>&yen;</code> - yen
**<code>€</code> - <code>&euro;</code> - Euro

==Bogdan Stăncescu==
Here are my findings related to automatic parsing of measurements on web pages while developing the [http://converter.mozdev.org Converter] extension. Please ask away if you want me to go into more detail on any of the topics -- I'm not sure which of my experiences are relevant to microformats, so I'm going to give you an overview of my conclusions.

By the way of an introduction, the Converter is a Firefox extension which tries to convert all measurements it finds in any web page to their Imperial or metric counterpart (e.g. Fahrenheit to Celsius, and Celsius to Fahrenheit; meters to feet and feet to meters). There are two steps to the conversion process: (1) identifying the measurements in the page, and (2) converting them. As expected, the conversion part is trivial, at least conceptually. The parsing is the tricky bit, and that's also where the Converter's challenges also become relevant for microformats.

Here are the main challenges I have encountered while writing the Converter:

;Presentation standardization: The first, biggest and most obvious challenge is lack of almost any ''de facto'' standardization in respect to data presentation. What I mean is that although the units themselves are more or less standardized (more on that later), they are ''presented'' in various ways within web pages. Take these examples: "50 foot monster", "50 ft monster", "50 feet monster", "50-foot monster", "50-feet monster" -- and my personal favorite, "fifty-foot monster" (more on this later);

:Note that using a microformat using in particular the [[abbr-design-pattern]] would make each of these examples less ambiguous if not unambiguous. See below --[[User:Guillaume_Lebleu|Guillaume_Lebleu]]:

<pre>
50<abbr class="unit" title="FOT">foot</abbr> monster
</pre>

<pre>
50<abbr class="unit" title="FOT">ft</abbr> monster
</pre>

<pre>
50-<abbr class="unit" title="FOT">foot</abbr> monster
</pre>

<pre>
50<abbr class="unit" title="FOT">feet</abbr> monster
</pre>

<pre>
<abbr class="value" title="50">fifty</abbr><abbr class="unit" title="FOT">foot</abbr> monster
</pre>

:: Of course; as far as I could gather, that's actually the ''purpose'' of microformats -- bridging the gap between what humans and machines can understand, no? --[[User:BogdanStancescu|BogdanStancescu]] 00:30, 11 Oct 2006 (PDT)

;Unit standardization: I live in Europe, where I've always used the metric system. As such, this probably was a much bigger nasty surprise for me than it is for a user of the Imperial/U.S. Customary system: in the Imperial system, the units themselves vary depending on where you are -- miles, pints, and a whole lot of other units come in many different flavors, but they're all written the same in regular usage;

;Language: "1 meter" vs. "1 metre" is a reasonable difference -- but non-SI units are usually translated. Even some SI units have different plurals, depending on the language, although in theory SI units are actually denoted by ''symbols'', not "words", as to make them non-translatable, and truly international (hence the name of the SI). I haven't really given much thought to a solution towards parsing these, because I find it overwhelming for the time.

;The sheer number of units: surprisingly, most people don't realize just how many units we humans have invented. Just take a look here: [http://www.asknumbers.com/ asknumbers.com] -- see how many categories there are? Now click on Flow Rate -- a non-ubiquitous type of measurement. Three sub-categories only for flow rates! Now click on Volume Flow Rate and take a look at the number of units in those lists. Remember, those are just in one of the three categories for flow rate! The UNECE standard mentioned in the [[measure-formats#Measure_Formats|measure formats]] page is useful to define just that -- a ''standard'' set of units. But in practice there are a lot more being used out there.

:Do you have examples from the Web (a URL) of non-UNECE units. One possibility would be to provide the ability for a unit to be defined as a division of products of other units. This is consistent with the [[measure-formats#Systeme_International]], which defines 7 base units and all other units as derived units (of course some units, even though they are derived are much easily represented as simple ones). This is what XBRL has done for financial/accounting/reporting. See [[currency-formats#XBRL]] and theorical example (ampere acre per second) below --[[User:Guillaume_Lebleu|Guillaume_Lebleu]]:

::Unfortunately I don't have URLs -- almost at all -- with measurements, although I've been in the "business" for a while. The reason for this is that I collect URLs of pages I encounter which are not properly parsed by the Converter, and when I release a version which understands those, I delete the URLs. Also, I never intended to cover all units in the Converter myself, for a multitude of reasons -- therefore I was never interested in the more exotic ones.

Guillaume Lebleu's example
<pre>

<abbr class="unit" title="AMP">Ampere</abbr> <abbr class="unit" title="ACR">acre</abbr> per <abbr class="unit" title="SEC">second</abbr>

</pre>

::Regarding your idea of breaking down the units in base units, that's something I've also been toying with in my head for the Converter. For my particular application, it's technically more difficult to implement this breakdown. For microformats, it would be easier, but there still remains at least one potential problem: you end up with a huge mess in the page. If a standard is too complicated to follow, one tends to give up altogether.

::Consider a document which actually discusses some sort of current variation per farm, and therefore needs to repeatedly refer to ampere acres per second. For human use, they'd simply define the AAS somewhere at the top of the document, and then refer to AAS, KAAS or MAAS as needed. Maybe a similar approach should be considered for microformats as well:

<pre>
We define the

<abbr class="unit_name">AAS
as
<abbr class="unit" title="AMP">Ampere</abbr>
<abbr class="unit" title="ACR">acre</abbr>
per
<abbr class="unit" title="SEC">second</abbr>
.
</pre>

::And then use the "AAS" throughout the document as any other pre-defined unit. How would you define (and use) the KAAS (1000 AAS) or MAAS (1,000,000 AAS) though? Is there any standard way already to use data multipliers in microformats? Or should we discuss that? Or is it out of scope? --[[User:BogdanStancescu|BogdanStancescu]] 00:30, 11 Oct 2006 (PDT)

That's all I can think of as major hurdles right now. If I remember anything else, I'll post here. Please do give me feedback here if you want to ask more about any of the topics I touched above, or if you have other questions I might be able to reply to. --[[User:BogdanStancescu|BogdanStancescu]] 12:08, 9 Oct 2006 (PDT)

==Discoleo==
=== Measurement Classification ===

Because it is easier to provide examples, I will first list examples.

==== Categorical vs Ordinal Data ====

Various measurements may produce '''NON-Numerical''' values:
* a pain scale: '''most severe''', '''very severe''', '''severe''', ...
* or the TNM tumour classification system: T0, Tx, T1, T2, T3, T4, N0, ...

There is even a more fundamental issue related to numbers themselves, e.g.:
* '''Lists''' or '''Years''' are sometimes written using '''Roman Numbers'''
** however, the strings corresponding to ''Roman Numbers'', when sorted alphabetically, do NOT retain the correct order
** i.e. C (100) preceds L (50), which preceds X (10)
* there are other numbering schemes

==== A Single Value / Data Point ====

This is the most simple data format and pretty straitforward to implement.

* the distance between 2 cities is '''40 km'''
* the velocity is '''62 mph'''
* most other simple entires (...)

==== An Interval Measurement ====

* time: the shop is open between '''6am - 18pm''' on every day of the week, exept Saturdays from '''9am - 16pm''' and Sundays from '''9am - 13pm'''
**[[hcalendar|hCalendar]]? [[User:AndyMabbett|Andy Mabbett]] 09:24, 22 Nov 2006 (PST)

This is more about an interval measurement. Every variable can have 2 (or more) values, e.g.:
* the levels of rain fall were between 25mm - 35mm
* the maximum velocity of various cars was 220 - 250 km/h

Should these values be stored as separate values? [e.g. low / high]
Or should the microformats be able to store an interval?

See also the examples for statistical summaries below.

*Mark up each as a separate measurement, and wrap them in a "range" microformat? [[User:AndyMabbett|Andy Mabbett]] 11:36, 22 Nov 2006 (PST)

==== Matrices ====

* the GPS coordinates are '''12°14' N and 25°55' E'''
**[[geo|Geo]]? [[User:AndyMabbett|Andy Mabbett]] 09:25, 22 Nov 2006 (PST)
* the dimension of the box is '''3m x 2m x 0.55m'''
**this is three separate, single measurements, surely? [[User:AndyMabbett|Andy Mabbett]] 09:21, 22 Nov 2006 (PST)
** 3 x 2 x 0.55 cubic meter, still 3 measurements, BUT given as cubic meter => ONE measurement?
***Who writes 3x2x0.55 cubic meter? You'd write "3.3m3" [[User:AndyMabbett|Andy Mabbett]] 11:36, 22 Nov 2006 (PST)
** the surface was 2 x 3 square feet ???
***Who writes 2x3 sq ft? You'd write "2ftx3ft" or "6ft2" [[User:AndyMabbett|Andy Mabbett]] 11:36, 22 Nov 2006 (PST)

* IF we write "3.3m3" or "6ft2", we '''loose information'''
* IF I want a surface, I would prefer the '''sqare feet''' unit, and NOT '''...feet x ...feet'''
* writing for every measure a markup, will '''bloat''' the code extensively
** data matrices would be very effective here
*** how would you make such a matrix? There are different ways how such information can be "compounded". (length per time = speed, length * length = area). Maybe a we can group those measurements by a surrounding information, what the context is. --Emil 02:50, 25 Dec 2006 (PST)

==== Statistical Measurements ====

Often, a group of data is summarized using a statistics:
* the mean length was 1.3m (SD 0.12m, group size 22)
* the median age was 42 years (interquartile range 95% 18 - 97)

==== Measurement Scales ====

===== Accuracy vs. Precision =====

'''QUESTIONS'''
* How detailed should a measurement be stored?
**Microformats aren't for storing measurements; they're for "labelling" the measurements that are already present. [[User:AndyMabbett|Andy Mabbett]] 09:23, 22 Nov 2006 (PST)
* If Accuracy and precision are relevant to the measurement, how do we store these?

===== Standardization of Measurement =====

* sometimes we may need to store the calibration information / calibration curves
* we may need to store the reference point the measurement is based on
* we may need to store the '''normal values'''
** biomedical measurements are often laboratory dependent, so it does NOT make sense to have the measurement without the corresponding normal values
** e.g. anti-Hepatitis B surface antigen antibody (anti-HBs) Titer: 32 MIU/ml
*** normal: 0 (non-infected, non-past infection, non-immunity)
*** protective immunity: >10 MIU/ml
*** interpretation is however more complex, depending on other tests as well

== Emil Thies ==

From my understanding, this microformat should concentrate on the notation of a measurement. So there will be some aspects, which has to be covered (elsewhere?) to improve the automatic use it or this microformat only uses some base informationens (units / dimensions) and derives all used from those base / build-in once.

=== Dimension vs. Unit vs. Scale vs. Measurement ===

A measurement is the combination of a number (value) and a unit (kind).
* 3km (3 Kilo Metre = 3.000 Metre)

A unit is a view for a measure of a dimension. There are two kinds how units can be different to each user:
* Units Differ by Scale (Prefix)
** 3km is the same as 3.000 meter or 300.000 cm (Its the same unit, with a different prefix, which works like a factor for the value, to lower the amount of symbols / numbers. The scale should be an own element and we can make use of the standard prefixes, like they are defined on [http://aurora.regenstrief.org/UCUM/ucum.html#section-Prefixes The Unified Code for Units of Measure] or [http://www.w3.org/TR/mathml-units/#SI-prefixes MathML]).
* Different units of the same dimension can be transferred into each other.
** Metre is a unit of the dimension length.
** Foot is a unit of the dimension length.

A Dimension is a base-dimension (see SI-System) or a compound dimension.
* length is a base dimension
* time is a base dimension
* speed is a compound dimension (length per time). There for a measurement of speed has one number and two unit by a math expression, which form their own unit. e.g. 10 m/s (10 Metre per second).

If we express a measurement in a microformat by the unit, the dimension is indirect provided by it. But a microformat, which uses measurement as a part, needs to define the dimension of it, to keep the use of the unit as an user choice. So, we could have a general measurement element, which allows all kinds of units to use. As a derived format, we can have sub-formats, which limit the list of units (or define an alternate list) by only allowing specific dimension(s).

E.G.
* [[currency-proposal]], with the money element which uses the same elements value (should then replace amount), scale (should be introduced), unit (should replace currency) which is limit to the ISO 4217 list.
* length, which only allows units which measures the dimension length, like FOT, MTR ...

=== Identification of Units ===

There are so many Units around - not only the existing one. There are deprecated ones like from Rome empire etc. For example "[http://en.wikipedia.org/wiki/Foot_(unit_of_length) Foot]" is not an unique identification of a unit. There is not only the British and U.S., there are for example same old German ones, before those areas joined the international metre convention in 1875:
* 25 cm in Hessen
* 28,935 cm in Bremen
* 29,641 cm in Oldenburg
* 29,1859 cm in Bayern
* 30,385 cm in Meiningen-Hildburghausen
* 31,385 cm in Preußen
* 31,608 cm in Wien/Österreich
* 32,61 cm in Bad Homburg vor der Höhe
* 33 1/3 cm in der Pfalz

So there is the need of a unique identification of those units. I found two approach right:

==== In MathML ====

MathML [http://www.w3.org/TR/mathml-units/#definitionURL defines] the construction of an URI like:

<nowiki>http://base/units/unit name[/context][/country][#prefix]</nowiki>

<pre>
http://.../units/foot/de
</pre>

But as you can see, there is right now no way to distinguish the different German foots based on the area inside Germany. Furthermore the context is so variable, that the same unit can be described by different URLs.

==== In OpenMath ====

OpenMath [http://www.openmath.org/cdgroups/units.html defines] the units inside of content directories:

<pre>
http://www.openmath.org/cd/units_us1.xhtml#foot_us_survey
</pre>

So there is a unique URLs for a Unit, but not every Unit is covered.

=== Transformation of Units ===

A real benefit is the automatic transformation of a unit, so that the write can write the measurement in his context (e.g. in the U.S. foot, or a quote from an antike text in Rome Empire foot) and the reader can get a transformation in his context (e.g. the value in metre). There fore there is the need of additional transformation information. And there are some different kinds of transformation:

==== units of same dimension ====

e.g. foot to metre

==== units of compound but same dimension ====

e.g. metre/s and mach-number

==== compound measurement context ====

<pre>This switch works up to 5 Ampere by 220 Volt</pre>

The reader might to now, which Watt device he can attach (1100 Watt would be the answer).

<pre>The dimension of the box is 3m x 2m x 0.55m</pre>

There might be some question like:
* volume (3,3 m³)
* surface (17,5 m²)

=== Approach ===

A general measurement should make use of the following informations:

value: a number, which represents the amount of the measurement. The number should follow one of the following representation:
* natural (positive and negative): e.g. -1, 0, 1
* decimal fraction (positive and negative): e.g. -2.5, 0.123
* natural fraction (positive and negative): e.g. -2/3, 3/7
scale: a factor used to lower the needed numbers of the value. The scale should be either
* a letter to refer a build-in factor, which is defined in [http://aurora.regenstrief.org/UCUM/ucum.html#section-Prefixes The Unified Code for Units of Measure] or [http://www.w3.org/TR/mathml-units/#SI-prefixes MathML]).
* a number like defined on value
unit: the unit used for the measurement. The unit should follow one of the following representation:
* build-in short-form like defined on [http://www.unece.org/etrades/units.htm Standards for Trade and Electronic Business] (or any other defined list which will be defined as the standard list for this format)
* a reference to a unit definition. (I think there is the need of a markup/language to define new units and/or the transformation between units).

<pre>
<abbr class="value" title="5">Five</abbr> <abbr class="scale" title="k">kilo</abbr> <abbr class="unit" title="MTR">metre</abbr>
</pre>

when we have a defined sub-measurement format for length, it could also be written:

<pre>
<abbr class="value" title="5">Five</abbr> <abbr class="scale" title="k">kilo</abbr> <abbr class="unit" title="MTR">metre</abbr>
</pre>

==== List of possible Sub-Formats ====

Here is a (first) list of possible keywords for sub-formats and their unit list or compound kind:

* money - unit limit to the ISO 4217 List (or could be a sparate [[currency]] microformat)
* '''length''' - unit limited to e.g. MTR (Metre), FOT (Foot) ....)
** '''area'''
*** Either a measurement with units like MTK (Square Metre), FTK (Square Foot)
*** or a compound format with elements (width:length, height:length)
** '''volume'''
*** Either a measurement with units like MTQ (Cubic Metre), FTQ (Cubic Foot), LTR (Litre) ...
*** or a compound format with elements (width:length, height:length, depth:length)
* time or duration or '''period''' - unit limited to e.g. sec (second), min (minute) ...
* '''frequency''' - unit limited to Hertz
* mass or '''weight''' - unit limited to GRM (Gram), ...
* power or '''electricity''' - unit limited to AMP (Ampere), OHM (Ohm), ...

==Straw man==
Based on [[currency-brainstorming#Taylor_Cowan|Taylor Cowan's currency suggestion]], and [http://microformats.org/discuss/mail/microformats-new/2007-September/000921.html subsequent mailing list discussion], the following straw man (rendering the above sub-formats unnecessary) is proposed:

<pre><nowiki>

[value]


<abbr class="hmeasure" title="[value]">
[text]
</abbr>
</nowiki></pre>

Where "value" is a number-type pair ("3Kg", "456g") using [http://en.wikipedia.org/wiki/SI_units SI] or other standard unit-codes and where parsers must accept the formats:

*[unit-code][number]
*[unit-code][space][number]
*[number][unit-code]
*[number]space[unit-code]

and where the acceptable codes are to be determined.

Further comment is invited. A test page is available, at http://www.westmidlandbirdclub.com/test/measure.htm

===Notes===
*This is extensible, using agreed new codes for unusual or archaic measurements (say "FUR" for "furlong"); such codes could be contained in the microformat's profile.
*Otherwise, it works as-is for sub-divisions of currencies:

<pre><nowiki>
<abbr class="hmeasure" title="635mm">
2' 1"
</abbr>
</nowiki></pre>

:(2' 1" is "two feet one inch" in imperial measurement).

===Issues===
*is hmeasure the appropriate class-name?
*Is [[currency|money]] a separate microformat, or a measurement, with the ISO currency code as the unit-code?
*What standard sources for unit-codes exist?
**[http://www.bipm.org/en/si/ International System of Units]
*This is still susceptible to the [[accessibility-issues#abbr-design-pattern]]
*How should stops (.) and commas (,) be interpreted? [[User:TobyInk|TobyInk]] 04:13, 18 Nov 2007 (PST)
*Do we also need sub-classes?

<pre><nowiki>

The kg weight was, in total 5.

</nowiki></pre>

*If so, where would this be used? And are "unit-code" and "value" appropriate class-names?
*'''[http://en.wikipedia.org/wiki/Measurement Measurement errors]''' are fundamental in many technical and scientific fields, they must be supported. [[User:LucaPost|LucaPost]]

<pre><nowiki>

<a href="/depth" rel="tag" class="data-name">Depth</a>:
( 2.17 +/-
 0.02 )
x 103
<abbr class="unit-measure" title="m">meters</abbr>.

</nowiki></pre>

:#Here the actual physical quantity is better 'defined' with rel-tag, and the optional data-error is clearly identified with its own span; alternatively parsers might identify the data-error part by looking for the '±' html-entity.
:# The standard '''[http://en.wikipedia.org/wiki/Scientific_Notation scientific notation]''' requires the data and the error values to be rounded to the same number of digits; the exponential notation in powers of ten is useful to have a singular format for values of any order of magnitude.
:# data-error and exp are not needed outside scientific contexts, thus they would be optional; the above HTML still represents a semantic structure when they're left out.

===Suggested amendment 1===

*Use only:

<pre><nowiki>
<abbr class="hmeasure" title="[value]">
[text]
</abbr>
</nowiki></pre>

Where "value" is a number-type pair ("3 kg", "456 g") using [http://en.wikipedia.org/wiki/SI_units SI] or other standard unit-codes where the parser must accept the following formats:

*Single measurements - [number][space][[http://en.wikipedia.org/wiki/SI_prefix SI-prefix]][[http://www.bipm.org/en/si/si_brochure/chapter5/5-2.html SI-unit]]
*Compound measurements - [number][space][[http://en.wikipedia.org/wiki/SI_prefix SI-prefix]][[http://www.bipm.org/en/si/si_brochure/chapter5/5-2.html SI-unit]][/][[[http://en.wikipedia.org/wiki/SI_prefix SI-prefix]][[http://www.bipm.org/en/si/si_brochure/chapter5/5-2.html SI-unit]]

====Notes====
*The only values allowed are SI values and prefixes

<pre><nowiki>
<abbr class="hmeasure" title="635 mm">
2' 1"
</abbr>

<abbr class="hmeasure" title="635 km/s">
635 kilometers per second
</abbr>

<abbr class="hmeasure" title="0.5 m^3/s^2">
half a cubic metre per second squared
</abbr>
</nowiki></pre>

====Supported SI Prefixes====

* yotta Y Quadrillion -1 000 000 000 000 000 000 000 000
* zetta Z Trilliard (thousand trillion) - 1 000 000 000 000 000 000 000
* exa- E Quintillion Trillion 1 000 000 000 000 000 000
* peta- P Quadrillion Billiard (thousand billion) 1 000 000 000 000 000
* tera- T Trillion Billion 1 000 000 000 000
* giga- G Billion Milliard (thousand million) 1 000 000 000
* mega- M Million 1 000 000
* kilo- k Thousand 1 000
* hecto- h Hundred 100
* deca- da Ten 10
* deci- d Tenth 0.1
* centi- c Hundredth 0.01
* milli- m Thousandth 0.001
* micro- u Millionth 0.000 001
** There is already a unicode character for the micro, sign: µ (U+00B5). Better to use it than substituting a "u". [[User:TobyInk|TobyInk]] 03:56, 18 Nov 2007 (PST)
* nano- n Billionth Milliardth 0.000 000 001
* pico- p Trillionth Billionth 0.000 000 000 001
* femto- f Quadrillionth Billiardth 0.000 000 000 000 001
* atto- a Quintillionth Trillionth 0.000 000 000 000 000 001
* zepto- z Sextillionth Trilliardth 0.000 000 000 000 000 000 001
* yocto- y Septillionth Quadrillionth 0.000 000 000 000 000 000 000 001

====Supported SI Units====

*meter (m) - length
*gram (g) - mass
*kilogram (kg) - mass
*second (s) - time
*ampere (A) - electric current
*kelvin (K) - thermodynamic temperature
*mole (mol) - amount of substance
*candela (cd) - luminous intensity

====Supported Derived SI Units====
*hertz (Hz) - frequency
*newton - (N) force, weight
*pascal - (Pa) pressure, stress
*joule (J) - energy, work, heat
*watt (W) - power, radiant flux
*coulomb (C) - electric charge or electric flux
*volt (V) - voltage, electrical potential difference, electromotive force
*farad (F) - electric capacitance
*ohm (ohm) - electric resistance, impedance, reactance
*siemens (S) - electrical conductance
*weber (Wb) - magnetic flux
*tesla (T) - magnetic field
*henry (H) - inductance
*lumen (lm) - luminous flux
*lux (lx) - illuminance
*becquerel (Bq) - radioactivity (decays per unit time)
*sievert (Sv) - equivalent dose (of ionizing radiation)
*katal (kat) - catalytic activity

====Supported Non-SI Units====

*minute (min) - time
*hour (h) - time
*day (d) - time
*radian (rad) - angle
*degree of arc (deg) - angle
** Use instead U+00B0 (°, degree) [[User:TobyInk|TobyInk]] 04:06, 18 Nov 2007 (PST)
*minute of arc (') - angle
** Use instead U+2032 (′, prime) [[User:TobyInk|TobyInk]] 04:06, 18 Nov 2007 (PST)
*second of arc (<nowiki>''</nowiki>) - angle
** Use instead U+2033 (″, double-prime) [[User:TobyInk|TobyInk]] 04:06, 18 Nov 2007 (PST)
*steradian (sr) - solid angle
*square degree (deg^2) - solid angle
*litre (L) - volume
*tonne (t) - mass

====Units Defined by Microformats.org====

*celcius (cel) - temperature
** Use U+2103 (℃, degrees celcius) [[User:TobyInk|TobyInk]] 04:07, 18 Nov 2007 (PST)
*bit (bit) - computing
*year (y) - year
*inch (in) - inch
*foot (ft) - foot

====Supported SI Markup====

*solidus (/) - divisor
** Division slash (∕, U+2215) more appropriate [[User:TobyInk|TobyInk]] 04:09, 18 Nov 2007 (PST)
*caret (^) - exponentiation

==See also==
{{measure-related-pages}}

recipe-brainstorming

2008-05-30T15:59:48Z

Yde: /* Measure */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]

recipe-brainstorming

2008-05-30T15:41:43Z

Yde: /* Additional Suggestions */

= Recipe Brainstorming =

Towards a [[recipe|Recipe]] microformat. Please read the [[process]] before editing this page.

==Format-In-Progress==

This format-in-progress follows the restarting of Recipe development by [[User:Phae|Frances Berriman]] on 25th September 2007. Note that this Format-In-Progress section is intended to be edited to reflect the discussion that occurs on the microformats-new list, rather than being a free-form playground for schema.

; Editors
: [[User:BenWard|Ben Ward]] (Yahoo!, Inc.)
: [[User:Phae|Frances Berriman]] (BBC)

===Introduction===

Recipe is based on [[recipe-examples|examples]] and fields in [[recipe-formats|existing formats]].

The recipe microformat is designed for the mark-up of instructions for creating meals, drinks or food-based items.

===Root Class Name===

To be decided. Likely ‘hrecipe’.

===Property List===

Recipe properties, with sub-properties listed in parentheses, like (this), plurality indicated by square brackets, like this[]. Note that the draft property names may change, but their function should remain.

Optional and required for each field is explicitly stated at this stage. Fields without have not been determined.

* Title - Required.
* Summary – A short introduction, accompanying statement about the recipe. Optional.
* Author - An hCard for the author of the recipe. Optional.
* Date Published - Optional
* Photo[] - Accompanying image. Optional.
* Ingredient[] (Quantity [Optional], Name [Required], ‘Optionality’ [Optional], Preparation Notes [Optional]) - 1 or more required.
* Method - The block of text containing the method of the recipe. Required.

Ingredient > ‘Optionality’. States that an ingredient is optional to the recipe. Its absence should imply that the ingredient is required.

===Suggested fields for inclusion===

* License - using rel-licence attribution
* Tags - using rel-tag.
* Method > Steps or Method-Step[] as a child of Method. Imply ordered steps from an HTML list or explicitly mark-up ordered steps respectively.
* Yield – Quantity produced by this recipe
* Calories – per serving. May be part of the [measure] microformat in future.

===Known Issues===

* Mark-up of quantity would be enhanced by use of a [measure] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable _enough_ without explicit mark-up of values and units.

==RecipeML-based Brainstorm==

Excerpted from [http://conoroneill.com/2006/03/21/what-if-i-suggest-a-structured-recipe-format-and-you-critique-it/ 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. [[User:AndyMabbett|Andy Mabbett]] 06:41, 16 Nov 2006 (PST)
** Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. [[User:AlexanderShusta|α]]
**Units need separate microformat: see [[measure]]
**Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. [[User:SteveL|Steve Lewis]] 18:55, 11 Feb 2007 (PST)
*Preparation Time (overall time)
*Yield Quantity and Unit (4 pancakes or 5 servings)
**Calories per serving [[User:JohnLeMasney| John LeMasney]]
**Calories per ounce [[User:JohnLeMasney| John LeMasney]]
*Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. [[User:AlexanderShusta|α]]
**Author (Person) ([[hcard]]?)
**Submitter (Person) ([[hcard]]?)
**Source (Book Title etc)
*** could use the proposed [[citation]] microformat. [[User:AndyMabbett|Andy Mabbett]] 06:43, 16 Nov 2006 (PST)
**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 [[User:AndyMabbett|Andy Mabbett]] 14:46, 16 Nov 2006 (PST)
***Another vote for an ordered list, perhaps in the [[XOXO]] format. [[User:AlexanderShusta|α]]
*Photo (optional) [[User:IamCam|Cameron Perry]]
**Could be one per dish, or one for each (or for some of the) step(s). [[User:AndyMabbett|Andy Mabbett]]

== 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? --[[User:Yde|Yde]] 08:41, 30 May 2008 (PDT)
*Difficulty/Notes - Perhaps incorporation of [[hreview|hReview]] to describe difficulty (using rating) and general comments (review), as an optional field. [[User:Phae|Frances Berriman]]
*Suitability (e.g. vegetarian, vegan, wheat-free, etc.). Possibly [[rel-tag]]. [[User:AndyMabbett|Andy Mabbett]] 14:57, 16 Nov 2006 (PST)
*Ingredient Grouping - In baking you need to differentiate wet from dry ingredients. See also an [[recipe-examples|example recipe]] from [http://www.extratasty.com/recipe/46/cuba_libre extratasty.com] for useful grouping in cocktail mixing. [[SteveL|Steve Lewis]] 19:10, 11 Feb 2007
** Maybe this ingredient grouping can be used to express some alternative ingredients, like "mayonnaise or cream cheese". [[EstevaoSamuel|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:<pre><nowiki>
<ul class="ingredients">
<li>Booze
<ul>
<li>1 part Rum</li>
</ul>
</li>
<li>Mixer
<li>1 part Cola</li>
<li>1 part Lime juice</li>
</li>
</ul>
</nowiki></pre> --[[User:Yde|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: <pre><nowiki>
Take a handful
of spinach and fry it
</nowiki></pre> --[[User:BenWard|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. --[[User:Yde|Yde]] 13:51, 23 Apr 2008 (PDT)
* Number of dishes or similary - often it's mentioned how many dishes (or breads in baking, etc) the ingredients are for. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Suitable for occations - what occations are the dish suitable for? [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)
* Category - many sites categorize their recipes. [[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)

Note: Comments added ''"[[User:WilleRaab|WilleRaab]] 16:57, 20 Jul 2007 (PDT)"'' are added after looking at http://tasteline.com, example: [http://www.tasteline.com/default.ns?strItemID=showRecipe&intChannelID=&lngRID=8045&tlfo=0 here].

*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? [[User:Lee Jordan|Lee Jordan]] 20:55, 04 Feb 2008 (GMT)

=== Proposed Ingredient List Optimisation ===

[[User:TobyInk|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.

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

is a shorthand for:

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

I agree. This would save a lot of space, especially combined with the proposed hmeasur [http://microformats.org/wiki/measure#hmeasure minimisation technique]. --[[User:Yde|Yde]] 12:57, 18 Apr 2008 (PDT)

=== Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work.

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

(note the double-space between '3' and 'eggs') is treated as a shorthand for:

<pre><nowiki><li class="ingredient">3 eggs</li></nowiki></pre>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, name) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as:

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

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

=== Alternative Proposed Ingredient Name/Quantity Optimisation ===

[[User:TobyInk|TobyInk]] 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but:

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

Or is this stretching the meaning of <var> too much?

=== Proposed Ingredient Name Optimisation ===

--[[User:Yde|Yde]] 02:12, 23 Apr 2008 (PDT):

If no class="quantity" or class="name" is found, the content of the ingredient element is treated as the name of the ingredient.

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

is a shorthand for:

<pre><nowiki><li class="ingredient">salt</li></nowiki></pre>

NOTE: To avoid confusion, I used the class name "name" although I think it should be changed to "item".

== Cookcamp brainstorming ==

At [http://barcamp.org/CookCamp CookCamp] in February 2007, Tantek moderated a fairly free form discussion of how to publish/share recipes. Here is a [http://flickr.com/photos/tantek/422072573/ photo of the whiteboard]:

[http://flickr.com/photos/tantek/422072573/ http://farm1.static.flickr.com/162/422072573_9956d93f61.jpg]

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

==Issues==
Please do feel to add your comments below. If this section grows too large, please create a seperate recipe-issues section. Thanks!

===Scope===
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
===Measure ===
{{OpenIssue}}
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)

*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)

*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)

*Should the hmeasure class be applied to all ingredient list items (i.e. <code><li class="hmeasure"></code>) or just the ingredients list itself (i.e. <code><ul class="hmeasure"></code>)? All ingredients are related to measurement (a value, a unit and an item) so it might as well be defined once or am I missing something? --[[User:Yde|Yde]] 12:37, 18 Apr 2008 (PDT)

*On the [[measure]] site it says: The names "value" and "type" are taken from [[hCard]]; "item" is used from hReview. For the same reasons, should we change quantity to value + unit and name to item or does this brake compatability with some recipe format? --[[User:Yde|Yde]] 13:25, 18 Apr 2008 (PDT)

==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:

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

or simply (if the proposed "[http://microformats.org/discuss/mail/microformats-discuss/2008-January/011199.html sub-microformat-pattern]" is adopted):

<pre><nowiki>
I like to eat cheese for supper.
</nowiki></pre>

: [[User:AndyMabbett|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?
--[[User:Yde|Yde]] 12:46, 18 Apr 2008 (PDT)

==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 [[recipe-examples#Menus|menu examples]].
: [[User:AndyMabbett|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" - [[recipe-brainstorming#Introduction | introduction]]) --[[User:Yde|Yde]] 13:39, 23 Apr 2008 (PDT)

== See Also ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]