Open Recipe Format - Rough Notes
Joseph Hall
- 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.
Harley J Pig
> another field, such as source_notes?
What about separate files. A source could be used for multiple
recipes, and multiple sources could be cited for one recipe. Make it a
reference to another table I think.
Joseph Hall
our people right now. I'm wondering if we should create a second group
for technical discussion, so that we can reserve this group more for
functional requirements. What do you all think?
jayce...@gmail.com
on the recipe.
Also, is the interchange storage the place to begin, or how about a
more relational schema, then work on the interchange?
goozbach
topics) sure
Joseph Hall
Let's try at the very least to keep technical discussion in seperate
threads, and maybe prefix the subject line with "Tech Discussion" or
something.
Just another thought.
On 4/20/06, goozbach <frio...@gmail.com> wrote:
>
> Seperate Groups may be a bit of overkill, a second topic (or group of
> topics) sure
>
>
> >
>
--
Joseph
Hans Fugal
I don't know about separate files, but a separate entity ('table' if you
will) is a good idea. Then your exchange only needs to detail a source once.
We can and should take advantage of YAML's ability to do this and not
worry about it ourselves.
Hans Fugal
Let's learn from GEDCOM. Two lessons: a standard interchange is more
important than any one program's model, and a poor interchange means no
end to misery.
Yes, we need to be explicitly aware of the underyling data model (which
needn't necessarily be relational), but we need to focus on the interchange.
Hans Fugal
We should stay as united as we can without driving the all-important
professional chefs away. If they would be driven away by our technical
discussions then we should split.
I imagine technical discussion will be the norm and less-technical
discussion the exception, so let's just prepend [chefs] to the subject
when it's to be non-technical.