Proposal of a Menu/menuItems schema? #1288
Comments
|
What if we added Than we could write something like this: Note: |
|
I think that gets very, very close to what I was envisioning. A few things I'd also consider:
and p.s. great to connect with you here as well as google+ ;) |
|
I don't love it but I don't hate it, @jvandriel. :-) I've been kicking around some ideas myself lately as I'd love to see a more robust way to mark up restaurant menus. But to be honest, I'm not a fan of the MTE Product-Recipe. I think those are two very different entities in the eyes of search engines. Maybe I'm wrong. But I would much rather push for a few new properties and types such as menu > URL or Menu, MenuItem, FoodItem, DrinkItem (just throwing out some initial ideas off the top of my head). We could then include some of the appropriate Recipe properties and types as well such as recipeIngredient, suitableForDiet, etc. I know that one of the arguments against creating new properties and types specifically for a certain entity is the desire to keep schema.org streamlined. But when you consider the vast number of restaurants in the world, we could argue that it might be worth exploring and developing a bit more because of the potential use and benefits. |
|
I have to say I don't have anything fixed in mind. Just thought I'd throw an example in there as a starting point. Tinker with it as much as you want to illustrate what you like to see yourself, maybe that way we can come to a proper proposal (and wider consensus). |
|
Is there a link to a formatting method that I should use to formulate a proposal? |
danbri
added
the
schema.org vocab
|
Along similar lines to above... (sorry for formatting, doing in spreadsheet) A few notes:
@type Restaurant |
|
Great to see interest about Menus, I too have been recently working on a I'd like to propose we expand the current property 'menu' on 'Restaurant' Menu would have two new properties: hasMenuSection --> MenuSection (aka MenuCatalog from above) hasMenuItem --> MenuItem MenuSection inherits from Thing > CreativeWork Through CreativeWork and Thing you can assert name and from offers: MenuItem inherits from Thing > CreativeWork add specific properties for suitable for diet (RestrictedDiet), allergens offers can contain all the pricing, variations with pricing and other Gordon Mackenzie | Schema Wrangler (Ontologist) | gmackenz@google.com | On Mon, Aug 15, 2016 at 10:31 AM, dkutcher notifications@github.com wrote:
|
|
Taking a stab... sorry for the formatting ` { |
|
I like it @dkutcher! I'd like to write up a quick proposal in the next day or so based upon what we've discussed so we can have something concrete to reference in further refining this schema. Looking at your example, I think we can use the existing CreativeWork.offers.Offer.validFrom instead of menuHours, startDate, and endDate as those three values can be captured in one validFrom.DateTime SO encoded value for duration and time intervals. |
|
I'm glad, and yes, that CreativeWork.offers.Offer.validFrom works, although it seems a bit funny to be thinking of a Menu as a creativework... very philosophical for a chef! To throw a quick stick in the cog, two situations that might not align neatly:
Thoughts? |
|
Related:
|
|
Bump? Anything I can do to assist? |
|
Hello, been away working on a complete proposal with @vholland and here's what I've come up with as a document. I think it answers all of the questions raised so far.
Price would be in Offer under Menu or MenuSection and the MenuItems will not list a price. That's how I would do it.
You can specify availability on Menu, MenuSection or in this case by MenuItem on the Offer's availability properties. Not sure which is better, some restaurants how unique specials items on a separate menu/menu section. Others might use multiple Offer on a MenuItem, each with a different price and availability time period. |
|
@gmackenz Can you make that document public? Can't see it...? |
|
On Wed, 10 Aug 2016 at 04:27 dkutcher notifications@github.com wrote:
Properties should include means to say whether the food is 'safe' for USE CASE: peanutAllergy https://www.wikidata.org/wiki/Q7157933 USE CASE: https://www.thecandidadiet.com/ Both should also support reputation/review properties... (ie: trusted
|
|
@mediaprophet agreed, I had put those under the NutritionInformation: "restrictedDiet":['vegetarian','gluten-free'] |
|
Sorry @dkutcher, I thought I had faithfully followed all the steps to make the document publicly visible. Here's an externally hosted version. Is this accessible for all interested? |
|
Can see that now- thanks. ~Richard
|
|
A few comments that I'm not quite sure are addressed:
Trying to think of situations... |
|
Additional question: Many sites have been using the menu property to supply a URL to the location of the menu. Within a restaurant website, all pages of the website might be pointing to site.com/menu.html If the menu property is now being extended, how would a restaurant property define the definitive location(s) of the menu(s), where they can then be found? |
|
On Tue, Sep 20, 2016 at 8:07 AM, dkutcher notifications@github.com wrote:
I don't quite understand, if you mean by the new extension of a Menu type |
|
Thanks for the questions and feedback! On Sat, Sep 17, 2016 at 11:57 AM, dkutcher notifications@github.com wrote:
|
|
I don't know the entire history of openingHours and openingHoursSpecification, but openingHoursSpecification is less ambiguous. It is clearer for both readers and writers of the data what is being said rather than parsing strings. |
|
I guess that means I need to go into all of my restaurant clients' websites
and update their hours schema!
|
|
I'm guessing that's probably because of how the And since Goodrelations has been an integral part of schema.org nearly from day one. I think it would be a bad idea to move away from it. (cc: @mfhepp) Having said that, I can imagine a purpose for using 'menuAddOn' in those situations where a FoodEstablishment has a separate MenuSection containing a group of additional menu items, eg Doing it this way means schema.org can facilitate menu's that don't have a separate 'add on' section on their menu but offer add ons directly from the MenuItem itself, while also being able to facilitate menu's that do have a separate 'add on' section. |
|
Hmm, I'm not sure if I'm a fan of using menuAddOn in that way. What about simply using the existing addOn property within the Offer? And really, the "add on" is not an addition to the menu but an addition to the menu item, right? So since many menu items also include the add-ons immediately below the item description, how about doing something like this (shown in a very simple, incomplete example)?: { Personally, I think that if a restaurant has an "add-on/extras" section, it might be easier to mark it up as it's own menu or menu section. But again, just my opinion. |
|
The addOn is a menu item being added onto a menu item. Caesar Salad
IMO the menu item is being modified here (item + sub-item). At the same time, the same item and sub-items might have different offers depending on time of day (for example). So it could be: Caesar Salad
That seems to me to make much more sense than nesting the chicken twice (once under each offer) |
|
Right. But I do think that your second scenario would probably be pretty rare to see. I think most restaurants typically have Lunch and Dinner menus as opposed to listing the item with various prices and times together. |
|
Perhaps, but they might have the regular menu discounted during lunch or happy hour, without having a happy hour menu. |
|
True. And honestly, there are several ways to mark it up, including the way you showed. But my main point is that I'm not sure creating a new menuAddOn property would be necessary. I think using the existing addOn property along with Offer would suffice, unless I'm overlooking something. |
|
The original intent was to allow for a specific add on sub-menus, which
many restaurants have currently (pizza restaurant menus are often listing
pizzas by type then provide a related but separate add on menu with prices)
Using addOn with Offer is perfectly valid but would make for a complicated
structure for those aforementioned restaurants if you list all the same
available add on items per menuItem.
Gordon Mackenzie | Schema Wrangler (Ontologist) | gmackenz@google.com |
…On Thu, Jan 19, 2017 at 11:48 AM, DDeering ***@***.***> wrote:
True. And honestly, there are several ways to mark it up, including the
way you showed.
But my main point is that I'm not sure creating a new menuAddOn property
would be necessary. I think using the existing addOn property along with
Offer would suffice, unless I'm overlooking something.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1288 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEeZIqqUo-NQdkFxXxydFKHMEp43-J-tks5rT73_gaJpZM4JgUxT>
.
|
|
I see and I understand where you're coming from, @gmackenz. When marking those up, could we possibly group all of the add-on items together in one add-on menu and reference it once for each menu item? Because the problem I see is that some restaurants will list the add-ons immediately under the item description but then other menus such as for pizza will list the add-ons all in a separate menu. So what about creating a new itemAddOn property that could expect a value of either MenuItem or MenuSection? |
|
I believe that was the intent for linking from various MenuItem(s) to a MenuSection of add ons items. Maybe I'm misunderstanding your suggestion but the listing add ons immediately could be done through your earlier suggestion of MenuItem > Offer > addOn > Offer. |
|
OK, let's try to make it a bit more concrete. I've taken the original markup example created by @dkutcher and tried to incorporate most of what's been said:
Anything that should be different folks? |
|
No, you're right, Gordon, it certainly can be done like that. I just didn't know if it would look strange for addOn to have an expected value of Offer or MenuSection. But the way you structured it would work perfectly for single add-on items. So for add-on menus, do you suggest doing something like this?.... ..... The MenuSection could be nested once or marked up separately. |
|
Thanks, Jarno. Sorry if I seem stubborn but I'm still not a fan of menuAddOn. A menu has menu sections but menu items have add-ons. If we already have Menu > hasMenuSection > MenuSection, why do we need menuAddOn to declare essentially another MenuSection? Can't we just use the same structure? |
|
Be as stubborn as you want, I'm not that crazy about it either. I just noticed it on http://webschemas.org/ earlier and tried to make sense of why it's there. Couldn't we let it out in favor of using |
|
Is using an MTE really necessary in this case, Jarno? Aren't menus, menu sections, and menu items by default understood to be "some products"? And MenuItem is going to inherit all of the Product type's properties anyway, so I'm thinking that it might be a little redundant and unnecessary. But perhaps I'm overlooking something. |
|
There are two things we need to keep distinct:
1. Support for configurable products ("choose three side-dishes out of a selection of ten"). This is a general requirement for products missing in schema.org, and it should be handled at the generic product level and not by a proprietary model for menues.
2. Support for add-ons that are offers to extend a base offer, i.e. you can only buy (or rent, in other domains) the product (accept the offer to buy or rent the add-on) if you accept the base offer, like "add a side-salad for only $3". This is already supported by schema.org via the addOn property - simply define two schema:Offer entities and link from the base to the optional extension via addOn. This is sufficient, precise, and generic.
Also, please try to keep the essential distinction between the objects that are being advertised (be they food, garments, or cars) from the *offer* to transfer some rights on the objects.
It would be a real pity if any domain-specific extension breaks this fundamental principle in schema.org, i.e. keeping products and offers of products distinct. This will always lead us into a mess as soon as we face bundles of products or services from multiple domains, like accommodations + foods, or rental cars and insurances, etc.
I strongly recommend reading
http://wiki.goodrelations-vocabulary.org/Documentation/Conceptual_model
and at least section 2 of the attached paper, which is an extension of the link above.
Best wishes
Martin
-----------------------------------
martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp
… On 19 Jan 2017, at 20:41, dkutcher ***@***.***> wrote:
Perhaps, but they might have the regular menu discounted during lunch or happy hour, without having a happy hour menu.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Good point. Thanks, Martin. We certainly don't want to break from schema.org norms. Do you have any suggestions then on how to handle these things? |
|
Going by Martin's comment I think it might be a good idea to remove |
|
Ok, I've added examples (thanks @gmackenz ! :) and also made a change that I wavered on previously. Rather than have yet another case where we have 2 very similarly named terms (a property 'menu' and a type 'Menu') I have added a new preferred property named 'hasMenu'. This property means exactly the same thing, and the old version can of course still be used, but it keeps us on course to having more distinct property names throughout. I expect we will fix all the other situations like this in our next release. |
|
I'm amazed by the new schema.org/Restaurant properties structuring markup possibilities. I've come through a few tutorials such as this one introducing the new Restaurant Menu markup, but I got stuck on how to markup individual Menu Items when viewing their actual single pages. E.g: For a Pizzeria Menu with different sections for pizza, pasta & beverages I'd markup the actual menu page like the following bellow, which is great, but, what about Restaurant Menus which allow viewing a specific Menu Item on its own single page? Could anyone please guide me on the proper method for marking up single Menu Items which exists alone on their own single page? Regards, |
|
@monecchi I would play with mainEntityOfPage the page vs. mainEntity. They are inverse to each other. The idea would be identify relations between entities |
|
So just to get this right, multiple menus in "hasMenu" are not possible, instead, nested "hasMenuSection" are used? |
|
|
This issue is being tagged as Stale due to inactivity. |
github-actions
bot
added
the
no-issue-activity
|
With the explosion of food delivery apps since this conversation has started, I think that the ecosystem has matured a lot. No longer does a restaurant exist as a brick-and-mortar location but also as a virtual shop. Wolt, Deliveroo, Takeaway, Grab, Uber Eats, we could draw on their insights on expressing the exact semantics a menu expresses. Its also probably required to somehow express the "location" of the menu (or Items?) to differentiate between items, sections, menus, or offerings that are available only on platform A and not in real-life or some other configuration. Or from a different angle, how do we signify whether the provider is a marketplace for the restaurant or direct? |
Currently for Restaurants and FoodEstablishments there is a menu item:
http://schema.org/Restaurant
menu
Text or URL
Either the actual menu or a URL of the menu.
But no schema for the menu(s) and menu items themselves.
For example usage, google a restaurant name + menu such as https://www.google.com/?ion=1&espv=2#q=two%20urban%20licks%20menu
You'll see the data of a menu being used in the rich formatting.
Is anyone developing the menu and menuItem schema? If not, how does one propose?
The text was updated successfully, but these errors were encountered: