Task: Refactor the Transport section

By the way, here is what ChatGPT says about our knowledge base structure:

The strongest part here is not the individual models, but how they fit together.

What is genuinely powerful here

KBConcept can essentially act as a universal site entity:

• country;
• region;
• city;
• district;
• beach;
• temple;
• airport;
• hotel;
• route;
• event;
• transport hub.

The concept already features:

• Parent / Children hierarchy;
• tree root;
• lat / lng / alt coordinates;
• multilingual names via KBLabel;
• files and images;
• facts;
• URL binding via SiteRoute;
• arbitrary structured data via Json.

In other words, a city, a landmark, and a route are not just CMS articles, but nodes in a unified knowledge graph.

And this aligns perfectly with VietnamGuru.

For example:

Da Nang → Son Tra peninsula → Linh Ung Pagoda → coordinates → opening hours → pricing → seasonality → transport → nearby places → article → map → route.

All of this can be stored not as a single massive block of text, but as interconnected knowledge.

The most promising part — facts are not strictly tied to a single entity

KBFact together with KBFactParticipation supports n-ary relationships: a single fact can link multiple concepts at once with different roles.

For a travel project, this is an extremely powerful model.

For example, the statement:

Bus No. 5 goes from Da Nang to Hoi An, stops near the Marble Mountains, and the ticket costs 30,000 VND.

Can be represented as a single fact involving:

• Da Nang — origin;
• Hoi An — destination;
• Marble Mountains — stop;
• Bus No. 5 — transport;
• 30,000 VND — value;
• validity period;
• source;
• confidence;
• verification status.

And if the price or route changes, the old fact is not destroyed. A new one is added with a new validity date. For travel, this is critically important: visa rules, prices, schedules, entrance tickets, and transport are constantly changing.

A full-fledged epistemic model is built-in here

What I especially like is that the database does not pretend to hold absolute truth.

Facts have:

• confidence;
• verified / tentative / disputed / deprecated;
• source;
• validity period;
• the date the fact became known;
• raw or derived status;
• derivation from other facts.

Plus, contradictions are treated as independent objects via KBConflict rather than simply being overwritten.

For a travel AI, this is a massive advantage.

A typical real-world scenario:

• Google Maps says the place is open until 18:00;
• The official website says until 17:00;
• A recent review says the ticket counter closes at 16:30.

A standard RAG would just output one of these options. Your model allows the agent to say:

"Sources disagree. The official stated time is 17:00, but visitors report earlier ticket office closures. It's best to arrive before 16:00."

This is no longer just a chatbot sitting on top of articles, but a proper intelligent travel assistant.

KBKnowledgeSpace unlocks yet another layer

Knowledge Spaces allow the exact same fact to have different:

• visibility;
• importance;
• confidence level;
• interpretation.

This can be used not only for privacy, but also for different product modes:

• editorial base;
• public base;
• user personal space;
• specific trip space;
• agent knowledge;
• partner content;
• unverified user data.

For example, a tourist creates a trip "Vietnam, August, family with a child." The agent can build a separate knowledge space where higher priority is given to:

• short transits;
• family beaches;
• air-conditioned locations;
• safe food;
• places without difficult climbs.

The same facts exist globally, but their importance shifts in the context of the trip.

SiteRoute makes the site structure an extension of the knowledge graph

The SiteRoute ↔ KBConcept connection is a brilliant idea.

This means the URL is not the entity itself, but a representation of the entity.

As a result, you can:

• change routes without losing the concept;
• build breadcrumbs from the tree;
• generate pages automatically;
• create regional sections;
• support old URLs via redirects;
• find entities without a public page;
• give a single object different representations.

For SEO, this is exceptionally valuable. Content architecture can emerge naturally from the graph rather than being manually maintained across multiple disconnected tables.

The map can actually become the interface to the knowledge base here

Now your explanation about the map looks even more interesting.

Since both KBConcept and File have coordinates, the map can display not just points from articles, but an entire spatial model:

• cities;
• landmarks;
• place-tagged photos;
• routes;
• nearby places;
• facts with geographical context;
• user saves;
• zones of interest.

And the agent can handle queries like:

"Show me interesting places within a 15 km radius of Nha Trang that are accessible without a motorbike and worth visiting after 17:00."

A standard article is not enough for such a query. But this schema potentially allows assembling an answer from coordinates, facts, relations, constraints, and user preferences.

By the way, some routes also have corrupted data.

"Can not get city2: \"cat-ba-island\"",
"Can not get city2: \"cat-ba-island\"",
"Can not get city2: \"cat-ba-island\"",
"Can not get city: \"cat-ba-island\"",
"Can not get city: \"cat-ba-island\"",
"Can not get city: \"cat-ba-island\"",
"Can not get city2: \"phong-nha-ke-bang\"",
"Can not get city2: \"nam-du-island\"",
"Can not get city2: \"nam-du-island\"",
"Can not get city2: \"nam-du-island\"",
"Can not get city: \"nam-du-island\"",
"Can not get city: \"nam-du-island\"",

Need to fix this along the way.