Re: Open Recipe Format
Hans Fugal
> 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.
Hear Hear!
> *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.
I recommend we use Tag URIs [http://www.taguri.org/], and so do the YAML
dudes.
> *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.
As I stated elsewhere, this should be either embedded, or be a link to
another part of the YAML document. Sources that wish to be reused should
probably have an ID (tag uri).
> - Should we store author (if known) in one field, and the rest of
> the source info in another field, such as source_notes?
I say we let it be free-form. I've seen no end of pointless endless
discussion for sources in genealogy data model groups, and all that
anyone really cares about is that you _have_ a source. Make it easy to
source, or nobody will bother.
> *Serving Size (Required)
> - Can be ounce, cup, each, etc
> - Will need to be stored as measurement, and amount
Fine, as long as the measurement can be vague, like "serving" or "Fugal
serving". This might should be optional, although required by policy at
some institutions.
> *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.
Again, what about Fugals? :-)
> *Difficulty Level (Optional)
> - Easy, Medium, Difficult, Expert? How many levels should there be?
I say we give a few 'standard' difficulties but allow this to be free-form.
> *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).
I say recommend a parseable format but leave it free-form. You're going
to hear that a lot from me.
> *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.
I think you forgot to mention that this is optional. ;-)
> *Ingredients (Required)
Are you implying you can't cook anything without food?
> - Need to list ingredient name, measurement (such as ounce) and amount
I think this works great. It would be good for us to recommend a
standard set of measurement spellings, so that software can make sense
of it and provide automatic scaling (however inappropriate it may be for
that particular recipe, it's still useful in general). Other cool things
that can be done are change to grams from ounces, or weights from
volumes (or vice versa). We don't need to concern ourselves about this
other than recommending a standard set of common measurement spellings.
I think another thing like "method" or "modifier" or comment or
something is in order as well, so that you can have 1 egg or 1 egg,
beaten. A common desire for food software is nutritional analysis, and
we want these two to both be "egg", but the preparation instructions are
different.
> - 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.
See tag uris. This kind of linking is central to GEDCOM, but one of the
great difficulties in this sort of thing is establishing the equivalence
of two entities from distinct sources (files). That's why I'm excited
about tag uris, they aren't specific to the enclosing file, they're easy
to come up with, and they're short. Duplicate recipe entities aren't
nearly as troublesome as duplicate people in GEDCOM, either. I would
expect software to let you sort by title and have a way to merge recipes
under a common tag uri.
> - 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.
Sounds good, and should be optional.
> *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".
If the chefs (I'll use this term to refer to the people who know more
about cooking than I do :) agree it should be itemized that's fine with
me. I think it wouldn't hurt for it to be free-form _or_ itemized; YAML
could handle that just fine, and software that wants to force
enumeration can do it as you said.
> - 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.
Hmm, that's a thought. We could have a (possibly/probably length one)
sequence of ingredient list+MOP.
> *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?
I say make it free form, with a recommended parseable format.
> *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.
We can allow either a URI (e.g. a file:// or http:// uri) or allow it to
be embedded (e.g. like a mime attachment).
> *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.
Just let people add whatever keys to the hash that they want, which are
free to be ignored.
>
> 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
This might be a good start for recommendation of measure spellings
and/or ingredient spellings. I think recommending that is all we need to
do to support nutritional info.
> 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.
Mastercook format is fairly straightforward, I think the above would be
considered a superset of it so let's call it supported. (let's do take a
closer look at it though). I haven't looked at RecipeML. Wasn't that the
one that you had to sign an NDA and sell your son into slavery to look
at the spec?
Joseph Hall
>
> Joseph Hall wrote:
>
> > - Should we store author (if known) in one field, and the rest of
> > the source info in another field, such as source_notes?
>
> I say we let it be free-form. I've seen no end of pointless endless
> discussion for sources in genealogy data model groups, and all that
> anyone really cares about is that you _have_ a source. Make it easy to
> source, or nobody will bother.
I have no problem doing the author/source free-form. Unless somebody
like Food Network is putting together a database, most of the authors
will be different. And if somebody like Food Network is putting
together a database, then they can use their own ID scheme (such as
tag uri) if they like. I do however think that we should be setting
some defaults in our format. A good default for this is "Anonymous".
If somebody leaves out this field, then it should be assumed that it's
anonymous.
> > *Serving Size (Required)
> > - Can be ounce, cup, each, etc
> > - Will need to be stored as measurement, and amount
>
> Fine, as long as the measurement can be vague, like "serving" or "Fugal
> serving". This might should be optional, although required by policy at
> some institutions.
>
> > *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.
>
> Again, what about Fugals? :-)
I think however these two fields are stored, they should be required,
or at least a default such as "1 batch" be implied if they are
missing. I was initially irritated when I was playing with ReciPants
and I discovered that these fields were required... that is, until I
decided to try and scale a recipe.
If you can procure a copy of the ChefTech software (I believe there is
a free version floating around), you will find that these fields are
not only required, they work together with another couple of fields
that all autofill each other.
> > *Difficulty Level (Optional)
> > - Easy, Medium, Difficult, Expert? How many levels should there be?
>
> I say we give a few 'standard' difficulties but allow this to be free-form.
The problem with free-form here arises when a program wants to include
a specific set of levels, and then tries to import a recipe with a
difficulty of "piece of cake" or "easier than my Aunt Verna after 6
drinks". If I were writing that program and I had to decide on a
default setting for these kinds of free-form settings, I would just go
with medium. And if the recipe ended up being some kind of sous vide
or a sacher torte, then I don't think the eventual cook would be too
happy.
> > *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).
>
> I say recommend a parseable format but leave it free-form. You're going
> to hear that a lot from me.
I say recommend a parseable format, but leave it optional. If you've
ever tried to parse NNTP headers, you'll find that even if there's
just 3 or 4 "standards" floating around for handling times and dates,
it gets to be a pain. Besides, while it may not be so important to a
home cook, a restaurant would make very good use of this field. A chef
could plan his entire day, week, or even month much more easily if his
software could accurately tell him how long to expect the process to
take.
> > *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.
>
> I think you forgot to mention that this is optional. ;-)
Yes, optional. But it fits in with prep time.
> > *Ingredients (Required)
>
> Are you implying you can't cook anything without food?
Thanks for that one.
> > - Need to list ingredient name, measurement (such as ounce) and amount
>
> I think this works great. It would be good for us to recommend a
> standard set of measurement spellings, so that software can make sense
> of it and provide automatic scaling (however inappropriate it may be for
> that particular recipe, it's still useful in general). Other cool things
> that can be done are change to grams from ounces, or weights from
> volumes (or vice versa). We don't need to concern ourselves about this
> other than recommending a standard set of common measurement spellings.
Yes, we should definitely set up some standard measurement spellings.
I can provide a list of common spellings and abbreviations this
weekend.
> I think another thing like "method" or "modifier" or comment or
> something is in order as well, so that you can have 1 egg or 1 egg,
> beaten. A common desire for food software is nutritional analysis, and
> we want these two to both be "egg", but the preparation instructions are
> different.
Good gravy, I didn't even think about modifiers! And an ingredient
could have multiple modifiers! I'm thinking of this field as an array.
Index 1 is the amount, index 2 is the measurement, index 3 is the
ingredient, and all subsequent indexes contain modifiers. So a field
that was pipe delimited might say:
2|c|butter|melted|clarified
Which would mean 2 cups of melted clarified butter.
> > - 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.
>
> Sounds good, and should be optional.
Should be optional, but I would still like to see a recommended
parseable format.
> > *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".
>
> If the chefs (I'll use this term to refer to the people who know more
> about cooking than I do :) agree it should be itemized that's fine with
> me. I think it wouldn't hurt for it to be free-form _or_ itemized; YAML
> could handle that just fine, and software that wants to force
> enumeration can do it as you said.
I don't think I can argue with it. I can only hope that they take it
upon themselves to number their steps though, and make it easier for
themselves and everyone else.
> > - 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.
>
> Hmm, that's a thought. We could have a (possibly/probably length one)
> sequence of ingredient list+MOP.
>
> > *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?
>
> I say make it free form, with a recommended parseable format.
What's with all this free-form? Maybe it's just me, but I'm thinking
that the more free-form we get, the less of a standard we have.
Eventually, we're back to just writing down recipes on index cards, or
even worse, typing them in MS Word. If we're going to do it free-form
and recommend a parseable format, then we need to be specific with our
recommendations. Most recipes will only have one oven setting, usually
something like 340F or 190C (we can't forget to specify imperial or
metric), though some will use multiple settings ("Varies, starts at
350F").
I still think we need to have a seperate field for the fan setting.
I've only ever seen 3 fan settings before: Off (mostly conventional
ovens), and Low and High (convection ovens). If a convection oven only
has Off and On, then then On setting is usually a Low Fan.
> > *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.
>
> We can allow either a URI (e.g. a file:// or http:// uri) or allow it to
> be embedded (e.g. like a mime attachment).
I like the embedded URI idea better than the attachment idea.
> > *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.
>
> Just let people add whatever keys to the hash that they want, which are
> free to be ignored.
Agreed. They'll be kind of like X-Headers in email.
> > 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
>
> This might be a good start for recommendation of measure spellings
> and/or ingredient spellings. I think recommending that is all we need to
> do to support nutritional info.
I would love to include support in the ingredient field for the
USDA-SR ID. Maybe an optional 4th field, before the modifiers? So our
2 cups of melted clarified butter now becomes:
2|c|butter|01145|melted|clarified
If they don't know the USDA ID, then they can just leave that field blank:
2|c|butter||melted|clarified
> > 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.
>
> Mastercook format is fairly straightforward, I think the above would be
> considered a superset of it so let's call it supported. (let's do take a
> closer look at it though). I haven't looked at RecipeML. Wasn't that the
> one that you had to sign an NDA and sell your son into slavery to look
> at the spec?
It was a pain, but I don't remember it being that much of a pain. ^_^
--
Joseph
Hans Fugal
suggestions. First, let me say I'd like this format to be
human-readable. As in, if you send me a recipe in this format but I
don't have any software that uses it, I could just print it out and be
able to use it perfectly well. It may be slightly verbose or less pretty
than a formatted recipe, but this is why I will advocate _not_ requiring
fields more often than not. Fields with meaningless words for defaults
(like "1 batch") just get in the way. This is not just a nifty thing,
btw, Mastercook exports are _very_ human-readable and a lot of people
really like that.
Joseph Hall wrote:
> On 4/20/06, Hans Fugal <ha...@fugal.net> wrote:
>> Joseph Hall wrote:
>>
>>> - Should we store author (if known) in one field, and the rest of
>>> the source info in another field, such as source_notes?
>> I say we let it be free-form. I've seen no end of pointless endless
>> discussion for sources in genealogy data model groups, and all that
>> anyone really cares about is that you _have_ a source. Make it easy to
>> source, or nobody will bother.
>
> I have no problem doing the author/source free-form. Unless somebody
> like Food Network is putting together a database, most of the authors
> will be different. And if somebody like Food Network is putting
> together a database, then they can use their own ID scheme (such as
> tag uri) if they like. I do however think that we should be setting
> some defaults in our format. A good default for this is "Anonymous".
> If somebody leaves out this field, then it should be assumed that it's
> anonymous.
Well, yeah, that's what anonymous means. :) Contrary to popular belief,
Anon. is not a person, and everything written by him was actually
written by a person. The only meaningful use of the word Anonymous I can
think of is when you want to point out that the author wishes to remain
anonymous.
>>> *Serving Size (Required)
>>> - Can be ounce, cup, each, etc
>>> - Will need to be stored as measurement, and amount
>> Fine, as long as the measurement can be vague, like "serving" or "Fugal
>> serving". This might should be optional, although required by policy at
>> some institutions.
>>
>>> *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.
>> Again, what about Fugals? :-)
>
> I think however these two fields are stored, they should be required,
> or at least a default such as "1 batch" be implied if they are
> missing. I was initially irritated when I was playing with ReciPants
> and I discovered that these fields were required... that is, until I
> decided to try and scale a recipe.
I disagree. Let the software imply the meaning of the absence of these
fields. If the software wants to require these fields for use in scaling
later, that's fine - it can ask for them when importing a recipe that
doesn't have them.
> If you can procure a copy of the ChefTech software (I believe there is
> a free version floating around), you will find that these fields are
> not only required, they work together with another couple of fields
> that all autofill each other.
That's great, but what about the ImNotAChefTech that my mom will not use
if she has to answer a thousand required questions for every recipe?
>>> *Difficulty Level (Optional)
>>> - Easy, Medium, Difficult, Expert? How many levels should there be?
>> I say we give a few 'standard' difficulties but allow this to be free-form.
>
> The problem with free-form here arises when a program wants to include
> a specific set of levels, and then tries to import a recipe with a
> difficulty of "piece of cake" or "easier than my Aunt Verna after 6
> drinks". If I were writing that program and I had to decide on a
> default setting for these kinds of free-form settings, I would just go
> with medium. And if the recipe ended up being some kind of sous vide
> or a sacher torte, then I don't think the eventual cook would be too
> happy.
Dealing with a free-form answer you don't understand can't be any more
difficult than dealing with the absence of this field. It is optional
after all.
Allowing free-form gives ImNotAChefTech users the flexibility to be
creative that they think they need, but most will use the standards.
In any case, difficulty is highly subjective. Easy for a chef may be
nigh unto impossible for aunt verna.
>>> *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).
>> I say recommend a parseable format but leave it free-form. You're going
>> to hear that a lot from me.
>
> I say recommend a parseable format, but leave it optional. If you've
> ever tried to parse NNTP headers, you'll find that even if there's
> just 3 or 4 "standards" floating around for handling times and dates,
> it gets to be a pain. Besides, while it may not be so important to a
> home cook, a restaurant would make very good use of this field. A chef
> could plan his entire day, week, or even month much more easily if his
> software could accurately tell him how long to expect the process to
> take.
Rethinking a little here, I think we can have one "time" entry that is
split out in prep, inactive prep, cooking, and whatever other standard
times we want. We could also allow nonstandard times, which the software
could fold in if it wants. For example, notachefware might have only one
field for "preparation time", and it wants to import this:
time: {prep: 15 minutes, inactive prep: 6 hours, cooking: 1 hour}
It could just add up all the time and say "preparation time 7 hours 15
minutes". If a bread baking shop has baking-specific software that wants
autolyse time, preferment time, between-deflate time, kneading time,
etc. then it would be perfectly able to do so, but we can't expect
notachefware to deal with it.
>>> *Ingredients (Required)
>> Are you implying you can't cook anything without food?
>
> Thanks for that one.
>
>>> - Need to list ingredient name, measurement (such as ounce) and amount
>> I think this works great. It would be good for us to recommend a
>> standard set of measurement spellings, so that software can make sense
>> of it and provide automatic scaling (however inappropriate it may be for
>> that particular recipe, it's still useful in general). Other cool things
>> that can be done are change to grams from ounces, or weights from
>> volumes (or vice versa). We don't need to concern ourselves about this
>> other than recommending a standard set of common measurement spellings.
>
> Yes, we should definitely set up some standard measurement spellings.
> I can provide a list of common spellings and abbreviations this
> weekend.
I think we should pick one spelling per measure for the interchange.
That lower the barrier to implementation. We can recommend that they
also understand nonstandard spellings as well. In RFC-speak, MUST use
these standard spellings on export, SHOULD (or MAY?) recognize these
other spellings too.
>
>> I think another thing like "method" or "modifier" or comment or
>> something is in order as well, so that you can have 1 egg or 1 egg,
>> beaten. A common desire for food software is nutritional analysis, and
>> we want these two to both be "egg", but the preparation instructions are
>> different.
>
> Good gravy, I didn't even think about modifiers! And an ingredient
> could have multiple modifiers! I'm thinking of this field as an array.
> Index 1 is the amount, index 2 is the measurement, index 3 is the
> ingredient, and all subsequent indexes contain modifiers. So a field
> that was pipe delimited might say:
>
> 2|c|butter|melted|clarified
I think we want something like
- {qty: 2, measure: cups, ingred: butter, modify: [melted, clarified]}
> Which would mean 2 cups of melted clarified butter.
>
>>> - 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.
>> Sounds good, and should be optional.
>
> Should be optional, but I would still like to see a recommended
> parseable format.
Sounds good.
>
>>> *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".
>> If the chefs (I'll use this term to refer to the people who know more
>> about cooking than I do :) agree it should be itemized that's fine with
>> me. I think it wouldn't hurt for it to be free-form _or_ itemized; YAML
>> could handle that just fine, and software that wants to force
>> enumeration can do it as you said.
>
> I don't think I can argue with it. I can only hope that they take it
> upon themselves to number their steps though, and make it easier for
> themselves and everyone else.
We can dream. ;-)
>
>>> - 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.
>> Hmm, that's a thought. We could have a (possibly/probably length one)
>> sequence of ingredient list+MOP.
>>
>>> *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?
>> I say make it free form, with a recommended parseable format.
>
> What's with all this free-form? Maybe it's just me, but I'm thinking
> that the more free-form we get, the less of a standard we have.
And the more strict we get the less we're able to accomodate everyone.
It's a balance.
> Eventually, we're back to just writing down recipes on index cards, or
> even worse, typing them in MS Word. If we're going to do it free-form
> and recommend a parseable format, then we need to be specific with our
> recommendations.
We definitely need to be very specific. In fact it should sound like
this is the only way to do it, with "but this field may be free form" in
small print at the end.
> Most recipes will only have one oven setting, usually
> something like 340F or 190C (we can't forget to specify imperial or
> metric), though some will use multiple settings ("Varies, starts at
> 350F").
Most, but not all, is the key. So what does "oven temp" mean if it
varies? Just the first temperature? If so, that's fine, we just need to
address that.
> I still think we need to have a seperate field for the fan setting.
> I've only ever seen 3 fan settings before: Off (mostly conventional
> ovens), and Low and High (convection ovens). If a convection oven only
> has Off and On, then then On setting is usually a Low Fan.
And I've only ever heard of ovens with controllable fans.
>>> *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.
>> We can allow either a URI (e.g. a file:// or http:// uri) or allow it to
>> be embedded (e.g. like a mime attachment).
>
> I like the embedded URI idea better than the attachment idea.
I think we need both. Aunt Melba doesn't have a place to stick images on
the web, and file:// is fairly useless in interchange.
>
>>> *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.
>> Just let people add whatever keys to the hash that they want, which are
>> free to be ignored.
>
> Agreed. They'll be kind of like X-Headers in email.
>
Precisely
>>> 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
>> This might be a good start for recommendation of measure spellings
>> and/or ingredient spellings. I think recommending that is all we need to
>> do to support nutritional info.
>
> I would love to include support in the ingredient field for the
> USDA-SR ID. Maybe an optional 4th field, before the modifiers? So our
> 2 cups of melted clarified butter now becomes:
>
> 2|c|butter|01145|melted|clarified
Again, use the hash instead of attaching meaning to positions in a list.
But yes. Got to start thinking like a data model guy not an RDBMS
programmer. ;-)
>
> If they don't know the USDA ID, then they can just leave that field blank:
>
> 2|c|butter||melted|clarified
>
>>> 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.
>> Mastercook format is fairly straightforward, I think the above would be
>> considered a superset of it so let's call it supported. (let's do take a
>> closer look at it though). I haven't looked at RecipeML. Wasn't that the
>> one that you had to sign an NDA and sell your son into slavery to look
>> at the spec?
>
> It was a pain, but I don't remember it being that much of a pain. ^_^
Yeah, I exaggerated. I never applied for access because I seem to
remember some sort of non-compete clause in his silly agreement.
Kabaju
this information to the user?
Aparently the format will be some sort of scripting language, but the
chefs aren't going to want to learn a scripting language to put in
their recipies. A gui front end will be required. I know all of you are
going, "well duh," but here's why I bring it up.
No matter how readable you make the format, if there are any sort of
tags then those who aren't used to scripting won't be able to make much
sense out of it. Hans mentioned sending a recipe file to someone who
doesn't have the program. Well it that's the case then we can present
two options:
1) They download their own copy of the program (It's not like they'd
have to pay for it)
2) The first person exports it to a pdf, or word document. That's
something that will need to be done anyways, since I'm sure chef's,
home cooks, etc will still want their hard copies anyway.
In other words I'd leave out the free form stuff and make as much as
possible a set format. You'll still want things like a form for
additional comments, or something like that. I recomend that the
ingredients be stored with metrics (gram, ltr, etc) then it will be
eaiser to scale up/down and the program can covert to cups/etc
Now for the GUI front end I'm thinking you should give the user a
beginning wizard to let them choose what format they want, like
1) The more traditional list of Ingredients, then the instruction list
2) Ingredients on one the left, instructions on the right, all in
groups. I havn't seen many recipies like this, but when I do, I really
enjoy it.
As mentioned before, the program can convert between measurement types,
therefore aplealing to profesionals, home cooks, etc. For example: lets
say I have a recipie I got from somewhere that says to use x grams
flour. I don't have a scale, so I want to convert to cups. I don't know
the conversion. But if I know that I'm putting it in my computer
database anyway, I can put it in there and it'll convert it for me.
(btw, I have run across recipies like this)
Joseph Hall
>
> You know, one thing that's confusing me is how are you going to display
> this information to the user?
>
> Aparently the format will be some sort of scripting language, but the
> chefs aren't going to want to learn a scripting language to put in
> their recipies. A gui front end will be required. I know all of you are
> going, "well duh," but here's why I bring it up.
I'm afraid you misunderstand, bro. We're not looking for a scripting
language. Nah, we aren't even looking for a language that most users
would even see. We're looking to create a storage format that would
accomodate the needs of the uers. In a way, I suppose we're looking
for a file format of sorts. 3rd party software would then need to be
written to support said format. The purpose of this group isn't to
write the software. Just the storage format.
> No matter how readable you make the format, if there are any sort of
> tags then those who aren't used to scripting won't be able to make much
> sense out of it. Hans mentioned sending a recipe file to someone who
> doesn't have the program. Well it that's the case then we can present
> two options:
> 1) They download their own copy of the program (It's not like they'd
> have to pay for it)
> 2) The first person exports it to a pdf, or word document. That's
> something that will need to be done anyways, since I'm sure chef's,
> home cooks, etc will still want their hard copies anyway.
The beauty of MealMaster was that the file format was human readable.
Perhaps a bit obtuse, but not so much that it got in the way. RecipeML
is not human readable, at least not without a good deal of effort,
because it's based off of XML, and is really chatty. I think I can
speak for Hans when I say that both of us are in favor of using YAML,
which tends to be very human readable.
> In other words I'd leave out the free form stuff and make as much as
> possible a set format. You'll still want things like a form for
> additional comments, or something like that. I recomend that the
> ingredients be stored with metrics (gram, ltr, etc) then it will be
> eaiser to scale up/down and the program can covert to cups/etc
>
> Now for the GUI front end I'm thinking you should give the user a
> beginning wizard to let them choose what format they want, like
> 1) The more traditional list of Ingredients, then the instruction list
> 2) Ingredients on one the left, instructions on the right, all in
> groups. I havn't seen many recipies like this, but when I do, I really
> enjoy it.
>
> As mentioned before, the program can convert between measurement types,
> therefore aplealing to profesionals, home cooks, etc. For example: lets
> say I have a recipie I got from somewhere that says to use x grams
> flour. I don't have a scale, so I want to convert to cups. I don't know
> the conversion. But if I know that I'm putting it in my computer
> database anyway, I can put it in there and it'll convert it for me.
> (btw, I have run across recipies like this)
Again, we're not writing our own GUI, at least not as a group. I will
personally be writing my own GUI, and hope that others will as well,
but that is not our scope here.
One of the things that makes this group different is that we have
included chefs in the process, not because we expect them to be able
to read or write code, but because we want to make sure that the code
that is written is what they need and want. I currently have three
chefs who have expressed interest (two of which are now on the list),
and am currently in discussion with more. As home cooks, we already
have a basic idea of what _we_ want, but I don't think that's enough.
--
Joseph
Kabaju
take into consideration how the GUI would be written for considerations
on how the standard should be built. Also I wonder if some sort of open
source interpreter/reader should be written so to help the format to
become sucessful. Afterall, would pdfs be so popular if acrobat reader
wasn't free? Anyways that's just my two cents on that, not something to
really debate a lot on.
As for the 'must have' things in the format, how about something for
alergy information? If there was a special way to tag a recipe saying
that it was designed for no wheat or no eggs then it would be very
helpful. For example my wife is alergic to whole wheat (white is fine),
but I have a teacher that is alergic to any kind of wheat (even
traces), my father in law is alergic to.... The list is so long now, I
can't keep track of it. Tags like that would be very helpful for
figureing out what to cook when company is over.
Joseph Hall
> take into consideration how the GUI would be written for considerations
> on how the standard should be built. Also I wonder if some sort of open
> source interpreter/reader should be written so to help the format to
> become sucessful. Afterall, would pdfs be so popular if acrobat reader
> wasn't free? Anyways that's just my two cents on that, not something to
> really debate a lot on.
Again, while something like that would be nice (and fairly easy in
Perl, I might note to the Ruby fans out there), it really is outside
the scope of what we're trying to accomplish.
> As for the 'must have' things in the format, how about something for
> alergy information? If there was a special way to tag a recipe saying
> that it was designed for no wheat or no eggs then it would be very
> helpful. For example my wife is alergic to whole wheat (white is fine),
> but I have a teacher that is alergic to any kind of wheat (even
> traces), my father in law is alergic to.... The list is so long now, I
> can't keep track of it. Tags like that would be very helpful for
> figureing out what to cook when company is over.
My first thought upon reading this was "wow! I didn't even think about
allergies!" And then as I thought about it more and more, I realized
that this is probably going to need to be a function of the software,
not of the format. If the code written to support this allowed the
user to specify which ingredients to avoid, then they could accomplish
this. Making a note in the recipe that "this dish is good for
so-and-so because they're allergic to wheat" is nice, but when the
recipe is passed along to somebody else (especially a complete
stranger), that information is essentially worthless, unless they are
also dealing with wheat allergies. In this case, they could make a
note in the recipe that says "wheat free", but a quick look at the
ingredients would also tell you the same thing.
--
Joseph