Travel platforms have to compress places. The difficult question is not how to preserve everything, but which distinctions can disappear safely, which ones change a traveler’s decision, and when a representation has reached the limit of what it can establish.
Imagine a small guesthouse where dinner is served once, at one shared table at 19:00.
The host shops and cooks for the guests who have requested dinner before noon. There is no second sitting and no late service.
A traveler expects to arrive at 21:00 and encounters a platform field that simply says:
Dining
There is nothing necessarily wrong with that representation. If the traveler wants to know whether the guesthouse serves food at all, it may answer the question perfectly well.
But it cannot answer the question that matters at 21:00:
Should we eat before we arrive?
A richer description would help:
Shared dinner at 19:00. Request by noon. No late service.
That carries the timing, the request deadline and the limitation. Yet even this more complete representation cannot establish whether dinner has actually been arranged for this particular stay.
The same dinner therefore produces several legitimate representations because the traveler is asking several different kinds of question.
The field has not become wrong.
The decision has changed.
Compression is part of the job
It is easy to criticize travel platforms for reducing distinctive hotels, guesthouses, routes and experiences to attributes.
Breakfast. Parking. Pool. Accessible. Restaurant. Pet friendly.
But that criticism is too simple.
A search result cannot reproduce an entire guesthouse. A booking card cannot carry everything a host knows. A map cannot preserve every characteristic of the territory it represents.
Every useful representation leaves something out.
The official platform documentation reviewed for this essay makes the checkbox caricature particularly difficult to defend. Booking.com documents accommodation responses that can include descriptions, important information, room details, policies and conditional facility information. Google documents hotel amenities, highlights and correction mechanisms. Airbnb’s accessibility guidance asks hosts for specific accessibility features, supporting photographs and further answers to guest questions. Google Places documents generated place summaries with defined category, language and regional limits, together with disclosure and reporting mechanisms.
The issue, then, is not that platforms compress places.
They have to.
The more useful question is what the representation can safely leave out for the decision it is being asked to support.
One representation, several decisions
Return to the guesthouse dinner.
| Traveler decision | What needs to be known | Is “Dining” sufficient? |
|---|---|---|
| Does this guesthouse serve food? | Existence of a dining offer | Yes |
| Can we eat there after arriving at 21:00? | Service time and late-service limitation | No |
| Do we need to arrange dinner in advance? | Request deadline and process | No |
| Has dinner been arranged for us tonight? | Stay-specific confirmation | No |
The same representation can therefore be useful at one stage of the journey and inadequate at another.
This suggests a more precise way to think about “flatness”.
A representation is not flat because it is short. It becomes too flat when it loses a distinction required for the decision it is being asked to support.
That distinction may be surprisingly small.
A room can accurately be described as sleeping four while the fourth bed is a sofa bed that changes whether the room fits a particular family.
Parking can accurately be described as available while requiring advance reservation.
A property can have step-free access at the entrance without that statement answering whether the bathroom works for the same traveler.
Late arrival can be generally possible while tonight’s 23:30 arrival still requires confirmation.
None of these examples proves that the shorter representation is badly designed.
The important question is whether it is being asked to do more than it safely can.
When a discovery fact becomes a commitment
This boundary becomes more important as travel information moves through search, summaries, assistants and agentic booking systems.
Suppose a dining attribute was originally created to help travelers discover properties offering food.
For that purpose, Dining = yes may be entirely appropriate.
Another surface may translate it into:
Dining available.
Still reasonable.
But now suppose a traveler asks:
We arrive at 21:00. Can we have dinner at the guesthouse?
If an automated system uses the discovery-level fact to answer “yes”, the original field did not necessarily fail.
The scope of the representation failed.
A fact suitable for discovery was promoted into an answer about a specific situation for which it did not contain enough information.
This distinction matters because fluent systems make the transition difficult to see. A filter looks like a filter. A concise AI answer can sound like a conclusion.
The danger is therefore not only information loss. It is a representation being reused at a level of decision it was never meant to settle.
Three needs that should not be confused
The dinner example also exposes three different requirements that can easily be collapsed into one semantic problem.
The publisher need
The guesthouse wants to describe what its dinner actually is.
It may matter that everybody eats together, that the host cooks one meal, that the request must arrive before noon, and that there is no late service.
Those details help the House explain itself honestly.
The traveler need
The traveler arriving at 21:00 does not necessarily need the complete story.
They may simply need:
There is no dinner after 19:00. Eat before you arrive.
That is not a sophisticated data model.
It is an excellent answer.
The modeling need
A developer or semantic architect may reasonably ask how dining format, service time, request deadline and availability conditions should be represented in reusable structured data.
That is also a legitimate question.
But the three needs are not interchangeable.
Publisher richness, traveler usefulness and modeling elegance are different objectives.
A richer ontology does not automatically produce a better traveler answer. A concise traveler answer does not necessarily capture everything the publisher wants to express. And an awkward modeling problem does not by itself prove that the public vocabulary needs to change.
That last distinction matters particularly to Tamaga because we work with Schema.org and semantic architecture.
Our first response to a tourism modeling inconvenience should not be to invent another term.
Before adding another field
When an important distinction appears difficult to represent, several possibilities should be tested before concluding that the public vocabulary needs to change.
Can the publisher already explain the distinction clearly in visible content?
Can current Schema.org represent the required concepts using existing properties?
Would multiple typing solve the use case?
Is there an existing general property that already carries the meaning?
Could a DefinedTerm or an external controlled vocabulary express the required classification?
Would a documented implementation profile provide enough consistency without changing Schema.org itself?
Is the missing element semantic at all, or is the actual problem a workflow in which somebody still has to approve, confirm or update the answer?
And, crucially, is there evidence that a consuming system needs the additional structure?
A new vocabulary term may produce a more elegant model while solving no consequential publisher or traveler problem.
That does not make modeling elegance worthless.
It simply means we should name the benefit correctly.
Accuracy is not quite enough
This leads to another distinction.
“Dining available” can be accurate.
“Sleeps four” can be accurate.
“Parking available” can be accurate.
“Step-free entrance” can be accurate.
Yet each can still be inadequate for the question the traveler is trying to settle.
For this reason, it can be useful to distinguish ordinary accuracy from what we might call decision-safe representation.
A representation is decision-safe when it preserves the distinctions required for the decision it is being asked to support, or makes clear that the next answer must come from somewhere else.
The second part matters.
Not every field should become richer.
Not every system should pretend to know more.
Sometimes the responsible representation is the one that reaches its boundary and stops.
Late arrival may be possible. Confirmation is still required.
That answer contains uncertainty, but it is more useful than a confident answer unsupported by the authority needed for this stay.
Identity is not authority
Structured systems are good at establishing identity.
A stable identifier helps two systems agree that they are referring to the same guesthouse. Structured data can make rooms, offers, policies, places and relationships explicit enough for other systems to process.
Those capabilities matter.
But agreeing about what thing we are talking about is different from knowing who can establish the answer to the next question.
A machine-readable policy may describe the general position.
The booking system may own current inventory.
The host may be the person who can confirm an exception.
A partner may be authoritative for tonight’s transfer.
These sources can all participate in one traveler journey without any one of them being the universal “source of truth”.
The useful architecture is therefore not necessarily one enormous canonical database.
It is an authority map in which consequential knowledge can still be traced to the source or responsible system able to establish it.
How to test what must survive
This does not require a theoretical exercise.
Choose one fact that could materially change a traveler’s decision.
It might concern room fit, accessibility, late arrival, parking, dietary provision, a transfer, a seasonal closure or a route limitation.
Start with the position closest to the source. Record what is established, which condition applies, when the information was reviewed, and who can change or confirm it.
Then inspect how that same fact appears across the surfaces the traveler actually encounters.
Keep the relevant context as stable as possible: dates, party, locale, device and capture time.
For each inspected representation, record whether the decision-changing distinction was:
- preserved;
- omitted;
- changed;
- contradicted;
- stale;
- or unestablished because the surface could not be inspected.
The current Tamaga method already uses this kind of distinction rather than treating every omission as equivalent.
The objective is not to count how many fields survived.
It is to discover where the representation stops being sufficient for the next decision.
A search card may omit a condition that appears perfectly well on the detail page. A detailed page may carry the general condition while a stay-specific request is still pending.
Absence on one surface is not proof of platform failure.
Likewise, technically correct presence is not proof that the traveler received the answer they needed.
A platform should know when to stop
The travel internet cannot preserve everything about every place, and attempting to do so would not make it more useful.
Some distinctions are safe to compress.
Others are expensive to lose.
The work is to know the difference.
Sometimes an attribute is enough. Sometimes the traveler needs one additional sentence, a photograph, a measurement or a date. Sometimes the answer depends on a live operational system.
And sometimes the next question belongs to a person.
That is where representation should hand over to authority rather than quietly impersonating it.
For Tamaga, this may be one of the more important implications of travel knowledge infrastructure.
The objective is not to make every representation richer.
It is to preserve what changes the decision, understand what can already be modeled with the tools available, and know where the representation must stop because somebody else owns the next answer.
A good travel platform does not need to remember everything about a place.
It needs to know what it can safely forget.
And when forgetting one more distinction would change the traveler’s decision, it needs to know where the next answer lives.
Scope and sources
The guesthouse dinner in this essay is a synthetic example. It is not a reconstruction of a Booking.com, Google, Airbnb or other consumer interface.
The platform observations are based on official documentation reviewed on 14 September 2026:
- Booking.com accommodation details: optional descriptions, facilities, policies and room details.
- Google hotel details guidance: amenities, services, highlights and correction mechanisms.
- Airbnb accessibility guidance: documented accessibility features, supporting photographs and host guidance.
- Google Places AI-powered summaries: summaries with documented category, language, regional, disclosure and reporting limitations.
These documents establish platform capabilities and guidance. They do not establish how every property is represented, what every traveler sees or understands, or any market-wide booking or visibility effect. The original W03 research package explicitly maintains those evidence boundaries.
Last reviewed: 14 September 2026
Correction state: No corrections recorded.