[perlhoser@gmail.com: Open Recipe Format]
Hans Fugal
emails from before the creation of the list that we should forward?
----- Forwarded message from Joseph Hall <perl...@gmail.com> -----
Date: Wed, 19 Apr 2006 11:24:38 -0600
From: Joseph Hall <perl...@gmail.com>
Subject: Open Recipe Format
WARNING: This is a longish email. The important parts are at the top,
and hopefully they're not nearly as long.
Everyone,
In the process of reviewing existing recipe software and writing my
own, I have come to a conclusion: there is not currently any software
on the market that, well, doesn't suck. If it even comes close to
doing what the cook needs, it involves such a complexity that nobody
wants to bother with it. If it's simple enough to use, it's largely
featureless and essentially useless. I don't know about you, but I'm
sick of it. So I have teamed up with programmer and sourdough freak
extrordinare Hans to create a standard for storing recipes.
I have written some rough notes off the top of my head about what
kinds of features I would personally like to see, and notes on other
things that I think are important. I would like to include
professional chefs in the review process so that we can make sure
their needs are kept in mind. Once we have a standard format for
storing recipes, software can be built upon this standard which can
actually serve the needs of both the professional and the home cook.
Because this format will be created with Open Source principles in
mind, it will be freely available for all to use, at no cost.
If you are interested in participating, or would like to suggest
somebody else that you think would be interested in helping, please
email me (don't use Reply-All) and we can set up a mailing list and
get to work. You don't need to be technically-minded to help. You just
need to be able to discuss with us what you need, so that we can
support it.
My notes are below. Thanks for your time, everybody!
*ID (Optional)
- This is something that would perhaps be more of a function of
the software, but needs to be supported in the recipe format. See
ingredient notes on why.
*Recipe Name (Required)
*Source (Anonymous if not known)
- Some sources can be quite lengthy, such as recipes from
FoodNetwork.com or from a listing from a book that includes full
bibliography format.
- Should we store author (if known) in one field, and the rest of
the source info in another field, such as source_notes?
*Serving Size (Required)
- Can be ounce, cup, each, etc
- Will need to be stored as measurement, and amount
*Number of Servings (Required)
- Serving size and number of servings are important for scaling
recipes, so they must be required, even if it comes out to Service
Size: 1 each, Number of Servings: 1.
*Difficulty Level (Optional)
- Easy, Medium, Difficult, Expert? How many levels should there be?
*Preparation Time (Optional)
- FoodNetwork lists "Prep Time" and "Inactive Prep Time". I think
that both are valid things to note. It may only take a few minutes to
make a marinade (Prep Time), but then it may take several days to
weeks for it to sit (Inactive Prep Time).
*Cooking Time
- A lot of recipes contain prep and cooking time, so it's
important to provide support for them if we wish to gain wide
acceptance.
*Ingredients (Required)
- Need to list ingredient name, measurement (such as ounce) and amount
- Some recipes don't scale using a perfect mathematical formula.
We need to be able to store multiple scalings for the same recipe. We
also need to be able to change the text, for the convenience of some
professional kitchens. For instance, one bakery may wish to note that
17 lbs 8 ounces can also be measured as 8 pounds 12 ounces twice.
- Some recipes, especially things like plated desserts, may call
for one or more recipes. For instance, a bakery may have a recipe that
calls for a certain type of cake round, a certain type of filling, a
certain type of garnish, all of which are seperate recipes that are
also stored in the database. We need to consider how to reference
other recipes. Some sort of ID would be ideal.
- It would also be nice to be able to reference things like
suppliers, and/or product codes for the product with each supplier.
This could be a custom comment field or fields, that is related
specifically to the ingredient, and that the software could support an
interface for, and then support an option to strip out later, such as
when printing.
*Method of Preperation, aka M.O.P. (Required)
- This part is really dicey. Some recipes use a numbering scheme,
or at least have the steps itemized, if not numbered. Some just have
one big blob of text. I would like to encourage itemizing each step.
Hopefully people that go with the big blob of text method would
reconsider having realized that it's saved as "Step 1".
- It's important to note that several recipes will go so far as to
group ingredients with steps. Some recipes will list the ingredients
to the left, and the steps for each group of ingredients to the right.
Some will provide a list of ingredients, followed by a list of steps,
followed by the next set of ingredients, and so on. I've found that
these methods can make the recipe much easier to follow, especially in
a production kitchen. In truth, many production kitchens will print
their recipes like this for this very reason. If we want to be taken
seriously for professional software, we need to take this into
consideration.
*Oven Temperature (Optional)
- A bakery that I worked at used templates for their recipes that
included the oven temperature, and whether or not the oven fan was on,
and even whether the fan was on low or high. Many home recipes start
by noting that the oven should be preheated to this temperature.
Should we store oven temperature in one field, and maybe fan setting
(Off, Low, High) in another?
*Notes (Optional)
*Photo(s) (Optional)
- I don't know how this would work out in our format, it's
probably something that's more of a consideration of the software, but
it might be important.
*Custom Field(s) (Optional)
- We need to be able to support custom fields for things that we
might have missed that a programmer may need to store. Hopefully if
they do come across items like that, they'll let us know so that we
can add them to future releases.
I would like to include some kind of support for nutritional data.
Fortunately, the USDA has already provided an incredibly useful
database, currently known as SR-18. Several websites have incorporated
past versions into their code, so it's not like it's uncommon. If you
would like to read up on their "Standard Reference", I have a link for
you:
http://www.nal.usda.gov/fnic/foodcomp/Data/SR18/sr18.html
We also need to take into account specs from MealMaster (or whatever
it was called) and RecipeML, since there are currently projects which
support these "standards". If we don't support something in one of
those that people think is important, then they'll be that much less
likely to go with our standard. And need I remind, that our standard
is being created for one reason alone: to raise the bar for kitchen
software. If we allow substandard "standards" to continute to
contaminate modern software, then it's just going to be that much
harder to clean up afterwards.
--
Joseph
P.S. We are currently working on setting up a website at
openrecipeformat.org. It's not up and running yet, but it will be
soon. If you decide to join the mailing list, I'll post a message
there when we're ready.
----- End forwarded message -----
--
Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach