menu-brainstorming

From Microformats Wiki
Revision as of 15:20, 4 December 2020 by Btrem (talk | contribs) (→‎Brainstorming: Adds discussion of menu container names.)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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)


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

See Also