Owned at the source. Interoperable at the edges.

Travel knowledge should be able to move without losing the source that can maintain, qualify and correct it.

Consider a fictional guesthouse whose North Room has a step-free route from the courtyard but an 8 cm threshold at the bathroom entrance. The guesthouse records both conditions, when they were checked and who is responsible for reviewing the record if the room changes.

A directory may use part of that information in a filter. A room page can explain the route and the threshold together. A traveler may need further measurements or confirmation of the current conditions before deciding whether the room meets their needs.

These are different uses of the same room record, not interchangeable answers. The property can verify its physical conditions; that does not make it the authority on what will suit every traveler. Nor does receiving the record make a directory responsible for establishing every fact about the room.

The challenge is to let useful information travel while keeping those responsibilities clear. Tamaga expresses that principle as owned at the source, interoperable at the edges: the organization can maintain the knowledge it is responsible for, while other people and systems can use appropriate representations of it.

Ownership means responsibility, not enclosure

“Owned at the source” does not mean keeping information inside a private database or requiring every traveler to visit the organization’s website. It means retaining the practical ability to maintain an approved record, explain its evidence and limitations, and correct it when circumstances change.

For the North Room, the record needs to distinguish the courtyard route from the bathroom entrance. It should identify the room, preserve the measurement and its scope, and make clear who can check it again. The guesthouse may share that information widely without asking every recipient to maintain an independently invented version.

In this doctrine, ownership describes responsibility for the record. It is not a statement about copyright, database rights or ownership of personal data. Licensing, access, privacy and contractual control remain separate questions.

Authority is specific to the claim, not automatically granted to the organization being described. A hotel may maintain evidence about its rooms while relying on a transport operator for a service timetable or another responsible body for a road closure. Publishing that external information should not erase the distinction between what the hotel establishes and what it obtains elsewhere.

The same principle applies when a traveler needs help evaluating a room. Staff can provide measurements, photographs and clarification, and confirm what is currently present. The traveler’s judgment about personal suitability should not be replaced by an unsupported promise that the room will work for them.

Source responsibility also leaves room for challenge. An approved record can be wrong, incomplete or out of date. Being identifiable as the source should make the organization easier to question and correct, not exempt it from scrutiny.

An edge carries a view of the knowledge

An edge is a point where another audience or system encounters the record: a public page, a directory listing, a partner feed, a booking interface or an API. What travels through it is a projection, meaning a selected representation shaped for a particular use.

Those projections do not need identical wording. A filter may identify rooms with a step-free route to the entrance, while the detail page explains the bathroom threshold. The important requirement is that the narrower statement does not become a broader claim that the whole room is step-free or suitable for every wheelchair user.

In the fictional example, a concise public description could read:

North Room: step-free route from the courtyard to the room. Bathroom entrance has an 8 cm threshold. See the property record for the measurement date and full details; contact the host for additional measurements or confirmation of current conditions.

This is not a complete accessibility assessment. It preserves two specific observations and a route to further information, without turning them into a universal judgment about suitability.

An edge should therefore carry enough meaning for its purpose and make the next source available when it cannot answer the remaining question. That does not require every card to display every piece of metadata. It does require the relationship between a short statement, its qualifications and its supporting record to remain recoverable.

Standards help information travel

Much of the supporting machinery already exists. W3C’s Data on the Web Best Practices recommends persistent identifiers, provenance, version information, licensing information, reusable formats and feedback routes. These practices address the relationship between data publishers and consumers, not just the production of a file.¹

Schema.org supplies shared terms for describing entities and their relationships, while JSON-LD provides a JSON-based way to serialize Linked Data.²³ Schema.org’s open-world approach also distinguishes omission from negation: a missing property does not establish that something is false.⁴ These mechanisms help systems exchange and interpret information, but their presence does not establish whether a particular measurement is current or sufficient for a traveler’s decision.

The distinction is practical: a shared format can carry a claim; it cannot substitute for the evidence and responsibility behind it.

Source responsibility and exchange are separate tests

A record can be well maintained and difficult to reuse. It can also circulate efficiently while nobody knows who last checked it. Treating “connected” as equivalent to “governed” hides both possibilities.

The two questions should be asked separately:

The first condition is the aim, not a certificate of truth or independence. A centralized service can preserve provenance and correction routes; a federated arrangement can still leave responsibility unclear. Choosing an architecture does not remove the need to decide who maintains each claim and how disagreements are handled.

Correction has to travel too

Suppose the guesthouse removes the bathroom threshold and updates its record. A directory still displays the old measurement, even though its connection to the property’s data remains technically available. The earlier observation may have been accurate when recorded, but it becomes misleading if the directory continues presenting it as current.

This is where exchange needs to be examined beyond the first successful publication. The receiving system must have a way to distinguish versions, discover relevant changes and update its presentation. A link to the source helps people investigate; it does not, by itself, update every copy.

The route matters in the other direction too. A traveler or partner may notice a discrepancy before the source organization does. The report needs to reach someone who can examine the evidence and amend the record where necessary. W3C’s best practices explicitly recommend gathering feedback and reporting errors to the original publisher.¹

For Tamaga, this leads to a practical requirement: the exchange should carry corrections back to the responsible source and carry verified changes outward again. A report is not automatically an approved correction, and updating the source is not proof that every dependent representation has been repaired.

A directory can correct its own presentation without silently rewriting the property’s approved record. The guesthouse can revise that record without assuming the directory has already refreshed its copy. Each side needs a clear responsibility, and the process needs to expose what remains unresolved.

This is not a promise of automatic synchronization across the entire travel internet. Where a channel requires a manual amendment, that work should be visible. Where a copy cannot be inspected or updated, the system should preserve that uncertainty rather than describe the correction as complete.

The removal of one threshold also should not become an unsupported claim that the room is now suitable for everyone. A correction should change the fact it establishes, not expand into a promise it cannot support.

A practical source-to-edge check

Start with one fact that could change a traveler’s decision, rather than an inventory of every field in the platform. The room threshold is one example; an arrival condition, parking restriction, meal deadline or seasonal transport service could serve the same purpose.

Ask five questions:

1. What decision depends on this fact? Identify what the traveler needs to understand, not merely what the system can store.
2. Who can establish it, and within what scope? Separate the organization’s own knowledge from information supplied by others and from judgments that belong to the traveler.
3. Which edges reuse it? Identify the public pages, partner records and interfaces where someone may encounter the answer.
4. Which qualifications and source details must remain available? Check the conditions, identity and date needed to interpret the statement, whether directly visible or accessible through a clear continuation.
5. How is an error reported, verified and corrected across those edges? Distinguish a report received, a source amended and an external representation updated.

This check does not require a new platform before it becomes useful. Its purpose is to reveal where responsibility is clear, where the information can travel, and where a correction would currently stop.

The principle behind the architecture

Owned at the source. Interoperable at the edges.

The source should remain capable of maintaining and correcting the knowledge it is responsible for. Each edge should carry the part it needs without becoming authoritative for questions it cannot settle. When another answer is required, the traveler or receiving system should be able to identify where that answer can be established.

For Tamaga, this is a principle of travel knowledge infrastructure, not a requirement that every fact live in one database or every interaction return to the organization’s website. Sharing and responsibility should reinforce one another. Knowledge can move widely while its conditions, sources and correction paths remain clear enough for others to use it responsibly.

The practical test is what happens after the room changes: whether the source can be corrected, whether the change reaches the relevant representations, and whether the traveler can distinguish the current answer from the one that used to be true.

---

Scope and sources

The North Room is a fictional example, not an accessibility assessment or an observation of a real property or platform. The doctrine and the two-axis comparison are Tamaga’s analytical position. The cited standards support specific publication and exchange mechanisms; they do not establish commercial outcomes, legal rights, accessibility suitability or the behavior of a live implementation.

The standards below were checked on 22 September 2026. DCAT 3 remains relevant background for dataset catalogs, data services and version metadata; it is not presented as a requirement for publishing an individual room fact.⁵

Related: What is travel knowledge infrastructure?

Footnotes

1. W3C, Data on the Web Best Practices. See the practices on provenance, versioning, persistent identifiers, feedback and republication, particularly Best Practices 5, 7–10, 29, 33 and 35. ↩ ↩²

2. Schema.org and its developer documentation, for the shared vocabulary and machine-readable definitions. ↩

3. W3C, JSON-LD 1.1, for JSON-based serialization of Linked Data. ↩

4. Schema.org, Style Guide, especially the open-world distinction in “Additional notes.” ↩

5. W3C, Data Catalog Vocabulary, Version 3, for catalog interoperability and resource version metadata. ↩