lists at ben-ward.co.uk
Wed Sep 26 09:15:13 PDT 2007
On 25 Sep 2007, at 10:29, Frances Berriman wrote:
> Just wondered who was last working on the recipe research, how it's
> going, and what's caused the current stand still? I'm quite keen to
> pick it back up again.
I've a passing interest actually, would be happy to contribute to try
and keep ideas rolling. Not sure how much concrete work I can produce
since I'm not really going to be publishing anything, but BBC Food
sounds like a pretty awesome base for you on that side of things.
Regarding the Brainstorm:
I'm a bit concerned by the current state of recipe brainstorming.
I'll work through it and give some thoughts of where it's gone awry
and my view on what I think is feasible and useful as a goal.
As the -examples page shows, recipes are published in a huge variety
of different ways. As such, I don't think we can expect to create a
useful format with very many ‘required’ fields. We can't expect
people to use precise measurements for quantities, nor even to
explicitly mark up the order of their steps in anything more than
flowing paragraphs. We don't seem to be able to expect people to keep
ingredients segregated from the instructions or use consistent
But I think if we accept that fluidity, we can still come up with
something simple, but robust and useful. I don't think we should get
too ambitious nor too generic. Talk on the brainstorming page about
being used for recipes for spells in computer games, or for making
bombs seems silly to me. I think better to focus on food and maybe
some future microformat for those things will be heavily based on
this recipe format (much like hListing is on hReview).
Going through the proposed fields, which are based somewhat on
RecipeML, I'll try to highlight where we've run too far, need to take
a breath and step back a little.
> Summary Description (one liner)
> Author (Person) (hcard?)
> Date (of Publication)
> License/rights (Copyright or other)
> Photo (optional, multiple)
All are common in all the other formats. That's to be expected here.
hCards and rel-licenses abound!
> Submitter (Person) (hcard?)
I don't understand what this is for. It seems superfluous.
> Source (Book Title etc)
Again, I'm not sure if there's a strong case for this. It just be
cited in the Summary of the recipe, using a future citeation
microformat if/when one exists.
> Measurement System (U.S., Imperial etc)
I don't see this being useful. Recipes do not use consistent
measurements: There are combinations of metric weights and
approximate ‘handfuls’ and ‘pinches’. Some recipes publish
both metric and imperial measurements alongside each other. I don't
think there's a reliable way to lock this down and it would be
expecting publishers to provide precise information that they don't
Instead, I think that parsers that require knowledge of the
measurement system should be expected to derive the measurement
system from the quantity with each ingredient. ‘10g’ as grams,
‘10oz’ and ounces and so on.
> Ingredients (each one a separate "item" rather than block text
with count/amount/range/unit broken out too)
‘Ingredient’ is pretty clear to me. The sub-parts are woolier
though, as follows:
> Units need separate microformat: see measure
No it doesn't! One day there might be a dedicated measurement format
but right now there isn't. Therefore I think that the ‘quantity’
of an ingredient should be considered the same way as ‘price’ in
hListing: Just a string which parsers may attempt to understand as
required. One day there might be a currency microformat, in which
case hListings will naturally adopt it within ‘price’. The same
attitude should be used here. A future ‘measurement’ format will
be an obvious compound part in recipes, but it is not required for
recipe to be specified usefully.
> Ingredient Preparation: such as diced, chopped, sliced, grated,
> Ingredient importance (e.g. Main, Required, Optional) should be
listed as an attribute of each entry.
I think all of this is trying to get too specific. For each
ingredient it seems appropriate to have an additional descriptive
string alongside the name and quantity, which may contain preparation
instructions and requirement. You might call it a ‘note’ or
> Background Information - Optional section to encapsulate
information that is useful but not necessarily required for a
I think the ‘summary’ would be an appropriate place for this
information. I don't see that it needs to be separated.
> Yield Quantity and Unit (4 pancakes or 5 servings)
> Preparation Time (overall time)
> Calories per serving
All are reasonable pieces of metadata to optionally include
> Calories per ounce
Seems too specific, and is tied to a measurement format there isn't a
reasonable way to represent. Maybe better that ‘calories’ be
represented as free text and again the ‘per serving’, ‘per
kilo’, ‘per ounce’ side of things be left to parsers (be they
human or machine).
> Meal Category (Starter, entree, dessert )
> Cuisine Category (Italian etc)
> Instructions (text, but can contain:)
> Steps (optional)
> Should be an ordered list Andy Mabbett 14:46, 16 Nov 2006 (PST)
> Another vote for an ordered list, perhaps in the XOXO format. α
I don't think this needs to be as explicit as this. As I mention in
my introduction, the way people write the ‘method’ of their recipe
varies wildly. Some write a few paragraphs of approximated
description, others a strict (or multiple strict) numbered lists of
I think that from a publication point of view, the best we can hope
for as a mandatory field here is ‘method’. Which may contain lists
or paragraphs, references to other ingredients or all sorts, but is
fundamentally the instructional part of the recipe. Beyond that is
too varied in publishing to define, and can be derived from existing
HTML semantics anyway.
A ‘method’ that is an ordered list is clearly steps, I don't see
that we need to make that explicit.
So, my feeling is that we should strip back what's been done, accept
that right now that explicit description of quantities and method is
unrealistic due to the variety of publication techniques and provide
a format that can things up simply, and consistently.
For those wanting a ‘field’ reference, the ‘fields’ I've
effectively identified in my response to the existing brainstorm are
More information about the microformats-new