Prior art
Questi contenuti non sono ancora disponibili nella tua lingua.
None of this was invented from nothing. ORDER exists because of a gap between these, not despite them — see Why ORDER exists for the shape of the gap. This page credits each of them individually.
schema.org
Section titled “schema.org”schema.org/Restaurant and schema.org/Menu are the web’s general-purpose vocabulary for a restaurant’s public profile — name, address, opening hours, menu, and whether it accepts reservations. It is what search engines read for rich results, and it is by a wide margin the most widely deployed restaurant vocabulary that exists.
ORDER’s schema.org projection tracks this vocabulary field-for-field wherever a term exists. ORDER did not build on top of it directly because schema.org is deliberately permissive — nearly everything is optional and cardinality is unconstrained, which is correct for a vocabulary meant to describe the whole web and wrong for an interchange format that needs to be able to reject an invalid document. More fundamentally, schema.org has no vocabulary for a table, a seat, a section of a floor, or a floor plan — the operational core of what a restaurant actually runs on has nothing there to inherit.
Restaurant Technology Network — menu synchronization standard
Section titled “Restaurant Technology Network — menu synchronization standard”The Restaurant Technology Network publishes an industry-built specification for synchronising menu data between a publisher (a POS or menu-management system) and its subscribers (delivery platforms, kiosks, and other downstream consumers) — message flows, menu and location setup, item availability changes, and limited-time offers.
It does the enterprise menu-distribution job well, and is the closest thing the restaurant industry has to a menu interchange standard. ORDER did not build on it because it is scoped to menu distribution specifically — it has no vocabulary for a floor plan, a table, or a service period — and its publisher/subscriber message-flow model targets ongoing system-to-system integration rather than a single portable document a restaurant can export, diff, and hand to a new platform once.
Reserve with Google availability feed
Section titled “Reserve with Google availability feed”Google’s Reserve with Google availability feed is the format a booking provider pushes so a restaurant’s real-time availability shows up in Google Search and Maps. It is very good at exactly one job: telling Google what is bookable right now.
ORDER did not build on it because it is structurally an output, not an interchange format — see Rules versus slots. It carries materialised slots (every date crossed with every time crossed with every party size); the underlying rule cannot be recovered from the slots. It is also a proprietary feed owned by a single consumer, not a published, independently implementable schema for the restaurant itself. ORDER’s own Google availability projection treats this feed as a derivation target, not a foundation — it is where ORDER’s rules end up, not where they come from.
Open Menu Format (OMF)
Section titled “Open Menu Format (OMF)”Open Menu Format is an open-source, vendor-neutral JSON format for menu and product data — names, descriptions, prices, photos, multi-language text — built to move a menu into a POS, a design tool, a delivery app, or a review site without proprietary lock-in. It does not model floor plans, tables, or reservations.
It is the open-source counterpart to the Restaurant Technology Network’s enterprise specification, and shares the same shape of gap: no floor plan, no table, no service period. ORDER’s menu/menu_section/menu_item entities are a closer cousin to OMF than to schema.org’s Menu type — both are trying to solve “let a restaurant own its menu data” — but OMF is menu-only by design, and the operational restaurant is the larger problem ORDER sets out to solve.