Once we had an architecture for the Knowledge Object, the next question appeared to be technical.
How should a KNOL be published?
Our earlier experiments with machine-facing knowledge had naturally drawn us toward structured representations. If machines were becoming independent consumers of public information, it seemed reasonable that they might require a representation designed specifically for them.
KNOL changed the order of that decision.
The architecture now existed independently of its serialization. We knew that a KNOL had a Primary Subject, coherent Knowledge Aspects, assertions, relationships, context, provenance, and conditions governing valid use. We could therefore stop asking which format we should use and ask a more useful question:
How much of this architecture can the Web already express?
That question brought us back to HTML.
HTML was designed to structure documents, not to implement KNOL. But documents already contain many of the structures knowledge requires. They have boundaries and hierarchy. They contain tables, collections, definitions, relationships, temporal values, and explanation.
Once we stopped looking at HTML merely as the container for a webpage, a surprising amount of the KNOL architecture was already there.
8.1 Look at the Document Again
Consider the Apex X5 Mark II Knowledge Object from Chapter 7.
At a high level, its architecture might look like this:
KNOL
Primary Subject: Apex X5 Mark II
│
├── Specifications
├── Video
├── Compatibility
└── ProvenanceNow consider an ordinary HTML document representing the same information:
<main>
<h1>Apex X5 Mark II</h1>
<section>
<h2>Specifications</h2>
...
</section>
<section>
<h2>Video</h2>
...
</section>
<section>
<h2>Compatibility</h2>
...
</section>
<section>
<h2>Sources</h2>
...
</section>
</main>There is nothing KNOL-specific in that markup.
The document does not formally declare that the Apex X5 Mark II is a Primary Subject. The sections do not formally identify themselves as Knowledge Aspects. We have not introduced a semantic vocabulary, RDFa, Microdata, Schema.org, or any custom KNOL syntax.
Yet the correspondence is obvious.
The document has one principal body of information. Within it are coherent sections representing different aspects of the subject. Those sections have labels that tell the reader what the enclosed information concerns.
The document structure is already preserving part of the knowledge structure.
This is an important distinction. KNOL does not assign new meanings to HTML elements. A <main> element means what HTML says it means. A <section> remains a section. A heading remains a heading.
KNOL simply recognizes that where the native meaning of an HTML structure honestly corresponds to the structure of the knowledge, there is little reason to discard that meaning and invent another container.
The Knowledge Object still comes first.
HTML gives parts of that object a native expression in the public document.
8.2 The Native Vocabulary of a KNOL
Once we looked at HTML from this perspective, a useful native vocabulary began to emerge.
Different forms of knowledge already had familiar document structures.
| KNOL role | Native HTML structure |
|---|---|
| Principal knowledge boundary | <main> |
| Knowledge Aspect | <section> |
| Subject, aspect, and hierarchy labels | <h1>–<h6> |
| Tabular or multidimensional knowledge | <table> |
| Term/definition or property/description knowledge | <dl>, <dt>, <dd> |
| Unordered collection or membership | <ul>, <li> |
| Ordered collection or sequence | <ol>, <li> |
| Addressable relationship | <a> |
| Temporal value | <time> |
| Explanation, qualification, and interpretation | <p> and prose |
This is not a KNOL markup specification.
Nor does the table imply that the HTML elements acquire formal KNOL semantics merely because we use them within a Knowledge Object.
The relationship works in the other direction.
If the publisher has modeled one principal body of knowledge and the document’s <main> content corresponds to that body, the native document boundary is useful.
If Costs and Compatibility are coherent aspects of the subject, sections can preserve those divisions.
If the knowledge is genuinely tabular, a table already exists for that purpose.
If the publisher needs to communicate a collection, HTML has lists.
If the publisher knows that order matters, an ordered list preserves that distinction rather than discarding it.
If the knowledge involves another addressable resource, a link can connect the two.
If the information is temporal, HTML can distinguish the temporal value from the surrounding text.
And if the knowledge requires explanation, prose remains available.
The point is not to maximize the number of semantic HTML elements on the page. It is to stop flattening different kinds of knowledge into the same representational form.
A publisher who has modeled the Knowledge Object is in a better position to recognize those differences.
That can matter to machines.
It can also produce a better page for people.
8.3 Tables as Reasoning Surfaces
Tables deserve particular attention because they illustrate the human-and-machine relationship unusually well.
Consider a camera publisher communicating three video capabilities:
| Video mode | Maximum frame rate |
|---|---|
| 8K | 30 fps |
| 4K | 120 fps |
| Full HD | 240 fps |
The same information could be expressed perfectly accurately in prose. The publisher could explain that the camera supports 8K recording at 30 frames per second, 4K at 120 frames per second, and Full HD at 240 frames per second.
The table does something different.
It establishes a common set of dimensions and places observations within them.
The reader does not need to reconstruct the relationship among each video mode and its corresponding frame rate from three clauses. The relationship is visible in the structure.
That becomes even more useful when the table grows.
A Medicare benefits table might compare dozens of services across in-network and out-of-network cost sharing. A product table might compare twenty cameras across price, weight, resolution, stabilization, and video capability. A location table might represent many plans through the same set of attributes.
In each case, the table establishes comparability before anyone asks a question about the data.
That connects directly to the Camera Catalog example from Chapter 2.
A future question may ask for cameras below a particular weight and price that also satisfy several technical requirements. When those products are represented through a common structure, the publisher has already performed some of the work required to make the comparison possible.
The table becomes more than a compact way to display information.
It becomes a reasoning surface.
This description does not depend on any claim that a particular answer engine prefers tables. Tables are useful even if no machine ever encounters them. People scan them efficiently. They work well for comparison. They can simplify dense factual information, particularly on pages where prose would otherwise become repetitive.
Our production work gave us another reason to pay attention to them. We repeatedly observed generative systems successfully extracting and working with information represented in ordinary HTML tables.
Those observations do not establish universal machine behavior. They do not tell us that every model processes tables in the same way or that a table receives some privileged status inside a proprietary system.
They show something more modest and more useful.
A structure already well suited to human comparison can also provide machines with regular relationships among labels, dimensions, and values.
The human and machine requirements can align.
8.4 Definitions Are Knowledge Too
Not every important piece of knowledge is a value.
Sometimes the consumer needs to know what the value means.
Suppose a Medicare plan has an in-network maximum out-of-pocket limit of $4,900.
The value matters.
So does the concept maximum out-of-pocket limit.
A beneficiary unfamiliar with Medicare may not understand what the term means, which costs count toward the limit, or why the number matters. A machine using the value in a comparison also benefits from having a stable understanding of the concept represented by the label.
The definition is therefore not merely explanatory material surrounding the “real” knowledge.
The definition is knowledge.
The same problem appears in less specialized domains.
A camera buyer may encounter in-body image stabilization, rolling shutter, or crop factor. A mortgage shopper may encounter annual percentage rate. A university applicant may encounter credit hour. A technical product may use terminology whose meaning determines whether two specifications are actually comparable.
HTML’s definition structures give publishers a native way to associate a term with its description:
<dl>
<dt>In-Body Image Stabilization</dt>
<dd>A stabilization system that moves the camera's image sensor to compensate for camera movement during exposure.</dd>
</dl>Again, the important point is not the tag.
It is the relationship being represented:
term → definition
Both consumers may need it.
This is another reason knowledge-native publishing should not be confused with stripping a page down to discrete facts. Sometimes making the knowledge more complete means adding the explanation necessary to interpret those facts correctly.
Definitions also illustrate why the architecture should remain separate from predictions about machine behavior.
In some of our experiments with deeper machine-facing manifestations, definition lists placed inside <template> structures were not consumed as consistently as comparable tabular structures. That was an observation about a particular experimental representation.
It was not evidence that definitions are unimportant or that <dl> is a poor structure in the visible document.
A definition can remain useful to the human reader regardless of what an external system does with it. And a machine capable of consuming the public document may encounter the same conceptual knowledge.
The architecture should therefore begin with what the publisher needs to communicate, not with an attempt to predict one downstream parser.
8.5 Structure Should Follow the Knowledge
Tables and definitions make the principle easy to see, but the same reasoning applies throughout the document.
If the publisher is communicating membership in a collection, a list may represent that knowledge more honestly than burying the members inside a long sentence.
If sequence matters, the representation should preserve the sequence.
If another public resource represents a related entity or concept, a link can connect the current Knowledge Object to that resource rather than forcing every related fact into the current page.
If time matters, the temporal value can be represented as time rather than left as an undifferentiated string.
If the knowledge is hierarchical, headings can preserve that hierarchy while giving it understandable labels.
And when the knowledge requires explanation, qualification, interpretation, or judgment, prose is not a fallback.
It is the appropriate representation.
This became one of the more useful consequences of KNOL for human publishing.
Modeling the knowledge first forces the publisher to decide what kind of communication is actually required.
A paragraph should exist because the reader needs a paragraph, not because prose happens to be the default material of content production.
A table should exist because the knowledge is tabular.
A list should exist because the knowledge is a collection.
A definition should exist because understanding the concept matters.
This can make pages more structured without making them more complicated.
In many cases, it makes them simpler.
The principle is therefore not “use more semantic HTML.”
It is:
Choose the native structure that most honestly represents the knowledge being communicated.
8.6 A Native HTML KNOL
A simplified camera KNOL can now bring those pieces together:
<main>
<h1>Apex X5 Mark II</h1>
<p>The Apex X5 Mark II is a full-frame mirrorless camera designed for still photography and high-frame-rate video.</p>
<section>
<h2>Specifications</h2>
<table>
<tr>
<th>Sensor</th>
<td>Full-frame</td>
</tr>
<tr>
<th>Resolution</th>
<td>45 MP</td>
</tr>
<tr>
<th>Weight</th>
<td>658 g</td>
</tr>
</table>
</section>
<section>
<h2>Video</h2>
<table>
<tr>
<th>4K</th>
<td>Up to 120 fps</td>
</tr>
<tr>
<th>8K</th>
<td>Up to 30 fps</td>
</tr>
</table>
</section>
<section>
<h2>Key Term</h2>
<dl>
<dt>In-Body Image Stabilization</dt>
<dd>A stabilization system that moves the image sensor to compensate for camera movement.</dd>
</dl>
</section>
<section>
<h2>Compatibility</h2>
<p>The Apex X5 Mark II uses the <a href="/lens-mounts/apex-z/">Apex Z lens mount</a>.</p>
</section>
<section>
<h2>Sources</h2>
<p>Specifications are based on the manufacturer's technical documentation updated <time datetime="2026-08-15">August 15, 2026</time>.</p>
</section>
</main>There is nothing exotic about the result.
That is precisely what makes it interesting.
A human reader sees a reasonably structured product page. The subject is clear. Specifications and video capabilities are easy to scan. A technical term is defined where it can help the reader. Compatibility connects to another resource. Source information remains visible.
At the same time, the document preserves a considerable amount of the KNOL architecture.
One principal body of knowledge is bounded. Its major aspects remain distinct. Tabular knowledge is tabular. A concept and its definition remain associated. A relationship is addressable. Temporal information is represented as temporal information. Prose carries explanation.
The page has not become a machine artifact.
It has become a more deliberate representation of what the publisher knows.
And yet it is still incomplete.
8.7 Where HTML Stops
Native HTML can tell us a surprising amount about how knowledge is structured.
It can establish that information belongs together. It can preserve hierarchy. It can distinguish tables from collections, definitions from ordinary paragraphs, links from plain text, and temporal values from surrounding prose.
It cannot always tell us precisely what those structures mean within the Knowledge Object.
A table can establish the relationship between a label and a value. It does not necessarily state that a particular value represents the body weight property of the Apex X5 Mark II, expressed in grams under a particular measurement condition.
A link can connect the camera to the Apex Z mount. The anchor alone does not formally state that the relationship means uses lens mount.
A section can keep related assertions together. It does not formally declare that the section represents the Video Knowledge Aspect of the Apex X5 Mark II.
The limit becomes especially important when a KNOL contains assertions about more than one subject.
Return to the Medicare example from Chapter 7. A KNOL may have Medicare Plan H5590-010-0 as its Primary Subject while performance information within that same object actually describes Contract H5590.
A well-structured HTML document can make the Performance section obvious to a human reader. Explanatory prose can make the contract relationship clear.
But native document structure alone does not provide a general mechanism for stating:
These assertions concern Contract H5590 even though the larger Knowledge Object concerns Plan H5590-010-0.
That distinction is part of what the publisher knows.
If it matters to correct interpretation, leaving it entirely implicit brings us back to the problem that started this book.
HTML has taken us remarkably far.
It has given the Knowledge Object structure without requiring a parallel machine document or a proprietary language. In many cases, the same structures that help machines also make the human publication clearer and more useful.
But structure and explicit meaning are not identical.
Sometimes the Knowledge Object knows more than native HTML can say by itself.
That is where semantic annotation becomes useful.