menu-brainstorming

This article is a stub. You can help the microformats.org wiki by expanding it.

Per process, for documenting ideas towards a restaurant menu microformat, based on experience and research into:

• menu-examples
• menu-formats

And of course using existing microformats as building blocks when appropriate.

Brainstorming

There may be some similarities with h-resume, which also has an h-card for the organization (e.g. restaurant) whom the resume belongs to.

The obvious path forward is to use h-product for menu items. h-product offers pretty much everything a menu item microformat needs: p-name for the item name, (e.g. mushroom soup), u-photo, e-description, and p-price. There are some additional things in menus, notably calories, that might require a new property. If a menu has a page for individual items, u-url is available. h-review might be useful for review sites like Yelp or Google (though that might be a disincentive for restaurants, which tend to harbor strong antipathy to review sites in general and Yelp in particular. I'm not sure if p-category can be reused, but some way to tag items -- as vegetarian, gluten-free, etc. -- would be useful. Btrem (talk) 02:12, 4 December 2020 (UTC)

Yes, p-category makes sense as a general tagging model. Gathering examples of categories used is useful to see what may be worth including as examples. Kevin Marks (talk) 15:04, 4 December 2020 (UTC)

What's missing is a container for the menu items. Such a menu container microformat could include meta information such as availability (e.g., a dinner menu is available 5pm -10pm). Btrem (talk) 02:14, 4 December 2020 (UTC)

A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., section class="starter foo-deliver". The starter classname would be a microformat spec, used by menus everywhere, while foo-deliver would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. Btrem (talk) 15:20, 4 December 2020 (UTC)

A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. Btrem (talk) 16:31, 4 December 2020 (UTC)

Ideas for property names:

• p-name for the name of menu, e.g. dinner, breakfast, etc.; or maybe desserts, wine list, appetizers, etc.
• p-seller - the retailer, i.e., restaurant, cafe, pub, etc, that is selling the menu items. This can be an embedded h-card. The name of this property should be generic enough to include a wide rage of food retailers, perhaps with the ability to include other types of businesses. Alternative property names for p-seller:
  • p-brand - this has the advantage of reuse from h-product, but that might be a disadvantage, too: menu items will likely be nested h-products, so using p-brand on parent and nested type might cause confusion. There's an additional problem: p-brand as restaurant name might be confusing for authors who might reasonably assume that a property called p-brand refers to the item brand, not the restaurant brand. In other words, a restaurant called "Bavarian Pub" that sells Franziskaner beer might assign "Franziskaner" instead of "Bavarian Pub" to a p-brand property. Thus, p-brand is a strong "pass" for me.
  • p-restaurant - simple and straightforward, but might give wrong impression of its intended use. I imagine a street vendor might not think of her/himself as a restaurant.
  • p-organization - very adaptable, but not very intuitive.
  • p-retailer - again, adaptable, but not as obvious as seller, and perhaps again might give wrong impression to street vendors or food kiosks.
• p-product -- the thing being sold, a beverage or dish, e.g., main dish, appetizer, dessert, beer, wine, etc. This can be an embedded h-product. The property name matches the embedded name, following the h-card convention which has a p-adr property that can be an embedded h-adr; and p-geo with optionally embedded h-geo. Also, p-product is both intuitive and adaptable. Obviously, a menu normally contains many items, so this would be a many-to-one relationship.

I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. Btrem (talk) 22:45, 8 December 2020 (UTC)

One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow h-menu to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. Btrem (talk) 22:06, 10 December 2020 (UTC)

For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. Btrem (talk) 00:38, 11 December 2020 (UTC)

I just came across the p-nutrition property from h-recipe, which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed h-product. But p-nutrition is not part of h-product. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. Btrem (talk) 00:57, 16 December 2020 (UTC)

There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on opening-hours. Minus my contribution to earlier today, there hasn't been any contributions since 2017. Btrem (talk) 22:42, 16 December 2020 (UTC)

Another idea for menu sections is to use the section element without any class name. A nested hx element would name the menu section ("appetizers", "dinner", etc.). It has the advantage of being native html5 and understood by or at least intuitive to authors. There are, however drawbacks. One is that it would require section where it is not convenient. One example is a menu using table markup, where sections are delimited by the tbody element. That could work with th standing in for hx, but that might be confusing. Probably not workable, but worth mentioning. Btrem (talk) 19:38, 18 December 2020 (UTC)

... feel free to add more unstructured thoughts there.

See Also

• menu