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:
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)
... feel free to add more unstructured thoughts there.