[uf-new] Recipe

[Ben Ward]

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  
measurements.

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.

 > Recipe_Title
 > 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  
currently.

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,  
minced, etc.
 > 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  
‘description’.

 > Background Information - Optional section to encapsulate  
information that is useful but not necessarily required for a  
successful recipe.

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)

Tags.

 > 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  
instructions.

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.


</brainstorm>

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  
as follows:

RECIPE
   TITLE
   SUMMARY
   AUTHOR
   LICENSE
   PUBLICATION DATE
   PHOTO(s)
   INGREDIENT
     QUANTITY
     NAME
     NOTES
   METHOD
   TAGS

Ben