The Problem HTML Solved 20 Years Ago — Your Organization Still Hasn't

In the early 2000s, search engines were struggling. Even when a page read <div class="title">, they couldn't tell whether it was the main topic of the page or an advertising headline. Pages with a lot of text were mistakenly interpreted as "information-rich." HTML was designed for visual layout and carried no semantics — no meaning.

Semantic HTML tags solved this problem. <header> declares that something is the introductory section of a page. <article> signals an independent unit of content. <section> creates meaningful chapter boundaries. Structure emerged that communicates "what is this" to machines — not how it looks, but what it is.

What matters is the essence of this shift. Semantic HTML did not increase content; it gave existing content a "type of meaning."

Semantic HTML wasn't enough. "Who is the author?" "When was this published?" "Is this a review, a how-to, or product information?" — HTML's tag vocabulary lacked the expressiveness to convey all of this.

That's where JSON-LD (Linked Data) came in. Using the vocabulary defined by Schema.org, it communicates the meaning a page carries to machines in JSON format.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "author": {
    "@type": "Person",
    "name": "Koshiro Nakagami"
  },
  "datePublished": "2026-05-02",
  "headline": "Article Title"
}

This is not mere metadata. This is an ontology. BlogPosting, Person, and Organization as defined by Schema.org form a vocabulary system that describes the relationships between concepts — in other words, an ontological vocabulary — and they assign meaning to individual pages.

@type: "BlogPosting" is a declaration that "this content belongs to the category of blog posts." author indicates a relationship with a person. publisher indicates a relationship with an organization. Meaning chains through a graph structure.

The reason Google can display rich snippets in search results — star ratings, FAQ displays, breadcrumb lists — is thanks to this structure. Machines stopped guessing and started reading structure.

Twenty years of Web evolution have proven certain design principles.

Principle 1: Meaning Must Be Declared to Be Communicated

<div class="important"> communicates to humans but not to machines. <h1> does. JSON-LD's "@type": "FAQPage" does. Only explicit declarations produce machine-readable meaning.

Principle 2: Relationship Types Complete Meaning

The relationship between "author" and "page" is typed by the author property. The relationship between "organization" and "logo" is typed by the logo property. A relationship without a type is as good as nonexistent to a machine.

Principle 3: Structure Cannot Be Retrofitted

Trying to add tags after the fact to a pile of unstructured content is like renumbering the chapters of a finished book. Meaning structure must be designed from the moment content is created.

These principles are not limited to the Web.

Your organization has knowledge. Support staff who know the product better than anyone. Sales reps who have a feel for market movements. Marketers who carry in their heads the rules for maintaining brand consistency.

But does that knowledge have "tags"?

"This is a rule for customer service." "This is a point of differentiation from competitors." "This is a prohibited word for the brand." — Is that kind of semantic typing in place?

The answer is probably no. In most organizations, knowledge exists in one of the following forms:

• Messages scattered across Slack channels
• Unnamed documents in someone's drive
• A veteran employee's memory
• An internal wiki that stopped being updated

This is the same state the Web was in during the early 2000s. There is content, but no machine-readable meaning structure.

OS iXanagi is designed as the answer to this problem.

Just as the Web has vocabulary like @type, author, and publisher for JSON-LD, OS iXanagi has a semantic vocabulary for organizational knowledge. That vocabulary is the 7 Core Domains.

Core Domain	Semantic Scope
Demand	Customer intent, problems, and needs
Commitment	Strategic positions, hypotheses, and policies
Fulfillment	Execution structure, routing, and delivery
Value	Delivered value and offers
Financial	Financial context
Relationship	Relationships between brand, company, and customer
Insight	Learning, growth, and validation

Declaring "this knowledge belongs to the Demand Domain" is structurally identical to writing <article> in HTML. It communicates to machines "what this meaning object is."

Furthermore, OS iXanagi has typed relationships. parent_of, contains, derived_from, contextually_cites — these serve the same role as author and publisher in JSON-LD. By typing the relationships between meaning objects, knowledge chains together as a graph.

Looking at the correspondence in practice, it becomes clear that both share the same design philosophy.

HTML Concept	OS iXanagi Concept
<article>	Meaning Object (Draft, Knowledge, FAQ)
<section>	Section (container of meaning)
<header>	Brief (article introduction / strategic premise)
@type: "BlogPosting"	semantic_tags: ["copy"]
@type: "FAQPage"	semantic_tags: ["question"]
author property	derived_from relation
breadcrumb list	parent_of relationship chain
canonical URL	group_key (locale-independent identity of meaning)

Particularly important is the correspondence between canonical and OS iXanagi's group_key.

HTML's canonical tag declares "the Japanese version and the English version are different expressions of the same concept." OS iXanagi's group_key means the same thing — group_key is an identifier that represents the "identity of meaning" across languages. Two Meaning Objects that describe the same concept in Japanese and English share the same group_key and are treated as a single node in the knowledge graph.

Why does this matter now?

Just as Google's crawler couldn't read "HTML without a meaning structure," AI agents cannot accurately leverage "organizational knowledge without a meaning structure."

For an AI to return a precise answer when asked "What are the prohibited words for this brand?", the prohibited words must be structured as "constraint objects belonging to the Relationship Domain in the Brand Profile." For an AI to follow the instruction "Write copy that reflects our differentiation points against competitors," those differentiation points must be registered as Strategic Thesis in the Commitment Domain.

OS iXanagi's Knowledge Engine functions as the single source of truth for this "machine-readable organizational knowledge." Whether the Marketing App is sending copy to the Website, the Support App is updating FAQs, or an AI agent is generating content — everyone references the same meaning objects in the same ontology_db.

This is the core of Compound Intelligence. The more knowledge is structured, the higher the quality of every AI action. Just as JSON-LD for the Web brought the benefit of "structure it once and Google displays rich snippets," knowledge that has been "structured once" in OS iXanagi simultaneously makes all Apps and AI agents smarter.

HTML's semantic markup was not created by engineers for themselves. It was the work of humans giving structure to their content so that AI — in the form of search engines — could accurately understand it.

There is no reason to leave that work confined to the dimension of "web pages." How to respond to customers, product differentiation points, the tone of the brand's voice — all of these are now processed by AI agents. Without structure, AI can only guess. And an AI that guesses rebuilds from scratch, every single time, the context your organization has spent 20 years accumulating.

Just as JSON declares @type: "BlogPosting", can your organization declare "what kind of knowledge this is"? That answer determines everything about your organization's AI readiness.