menu-brainstorming

From Microformats Wiki
Revision as of 16:31, 4 December 2020 by Btrem (talk | contribs) (Adds sig)
Jump to navigation Jump to search

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)


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

See Also