[uf-discuss] hRecipe - one suggestion, a lot of comments

[Thomas Loertsch]

Hi all,

as I already posted here we're planning to implement hRecipe at "essen &
trinken" [1]. I think hRecipe is in quite a good shape already. Cognition
[2] has recently included "experimental support for the proposed hRecipe
microformat" (though the document [3] is a bit vague about what exactly they
make required and optional respectively). As I'm not sure (and most probably
nobody is) how the standardisation process carries on, this experimaental
support at least seems to be a viable option to get things moving. But it's
also a reminder that there are some open issues which somehow have to be
resolved. And maybe there isn't so much more to clear out? But before I give
my comments to the open issues please let me open another one ;-)


* Suggestion: idle period / off-time / rest period / unattended time
You have to help me with the right english term here. What I mean is the
time that i.e. the dough needs to rise. When scanning a recipe for
practicality this is very important information. I'd like to suggest this as
an optional element. Please comment!


Now my 5 cents to the issues as summarized in recipe brainstorming [4]. I'm
trying to comment on all open issues, to help sort things out:

* Date published
I would leave the use of the datetime-design-pattern as optional (should).
Although it means stopping halfway by making the date machine retrievable
but not machine readable it is still better then nothing. And the issues
around datetime-design-pattern are not trivial.

* Ingredient
TobyInk proposes an optimization for Ingredient which makes sense, but...
first I wonder how much harder the optimization makes it to develop parsers.
And second the rule should be extended: if there is no <item>, <ingredient>
IS the <item> AND there cannot be any further <quantity>, <note> or
<optionality> for that ingredient. All in all that sounds too complex to me,
an accomplishment not worth the effort and therefor not in alignement with
the 80/20 principal. So I'm against it (not violently, though).

* Method
TobyInk proposes to make the method optional. Although most recipes rely
heavily on a method there are indeed those where it isn't necessary. If
80/20 does mean that easy or simple usecases should be facilitated it would
be in line with the principal to make the method optional. Since making it
optional doesn't hurt anybody I agree with TobyInks proposal.

* Suggested: Method > Steps or Method-Step
I'm against that. Outside 80/20. xHTML can do that alright. Also see below.

* Suggested: Calories
I'm all for that. Our site has nutritional information for calories,
proteins, carbohydrates and fat. That's also what european law demands as
information on packaged food. Most sites that I visited only listed calories
as nutritional information if they did at all. Allrecipes.com is the other
extreme with a huge list of nutritional information - clearly outside 80/20
imho.  Calories are a superordinate concept for proteins, carbohydrates and
fat. Nuitritional information is quite important for a lot of people.
I think calories are inside the 80/20 and should be included as an optional
element. 
A minor issue though: calories or joule? Most sites use Calories, but the
term is deprecated, and hMeasure uses Joule.

* Measure / use of hMeasure
There are a lot of units typically used in recipes that do not make much
sense in most other cases and therefor most likely will never make it into a
80/20-aware measure-microformat. This is a deliberatly short list:
- glass
- leave
- pinch
- tablespoonful
- teaspoonful
- lacing
- tie (??? my english is really leaving me here, hope you get the idea)
<note> can be used to indicate more subtle differentiation (like a "big
spoonful", "some leaves" etc). I think this list is both usefully short and
complete.
The following measures
- weight (gram)
- volume (litre)
- length (metre)
can be taken from the measure microformat. I guess measure is already stable
enough that it's save to use these terms "experimentally".
The measure-element should be optional. That way nobody is forced to select
a value from it - it's just a help to facilitate interoperability.

* Note
Note should stay as an optional value. There are so many ways to define
ingredients that it seems usefull enough to fit into the 80/20. And it's a
necessary addition to the proposed measurement-values above.

* Additional Suggestions - Steps, Ingredient Grouping
have both received negative feedback in comments. I could imagine a
<grouping> node, together with a <grouping-title> being useful for
ingredients as well as for steps (or authors or...). But wouldn't that
better be handled by another microformat? XOXO? Or by @section of HTML5?

* Additional Suggestions - Diffculty/Notes, Suitability
I'd rather not include these. Too diverse in the wild, better handled by
tags (at least in the first version).

* Scope
There seems to be a consensus that this is out of scope. Should be closed as
an issue.
* Single foodstuffs
make no sense imho. Should be closed as an issue.
* Menus
I would consider this out of scope too. Should be closed as an issue

* Multiple Items per Ingredient
I don't understand the problem. Since we're talking about free form text
entry fields you can easily define one item "salt and sugar" or two items
"salt", "sugar". Options can be noted in the <note> field.


Okay, hope this helps in advancing the format. Please give feedback!

Regards,
Thomas


[1] 
http://microformats.org/discuss/mail/microformats-discuss/2008-September/012
461.html
[2] http://buzzword.org.uk/cognition/
[3] http://buzzword.org.uk/cognition/uf-plus.html#hrecipe
[4] http://microformats.org/wiki/recipe-brainstorming





.
Thomas Lörtsch
Living at Home Multi Media GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas at guj.de