Difference between revisions of "menu-brainstorming"

From Microformats Wiki
Jump to navigation Jump to search
(→‎Brainstorming: Adds discussion of menu container names.)
(Adds suggestion for menu sections.)
Line 16: Line 16:
  
 
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., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 15:20, 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., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem|Btrem]] ([[User talk: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.
  
  

Revision as of 16:30, 4 December 2020

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

Per The microformats 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.


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

See Also