The Knowledge Object emerged from a machine-facing problem, but it did not remain one for very long.
Our original concern was straightforward. If external machines were going to retrieve pieces of published information and use them independently of the human reading experience, more of the meaning surrounding that information might need to be made explicit.
That suggested two consumers of the public Web.
People still needed pages designed for people. Machines increasingly needed to work with the knowledge contained within those pages.
At first, it was natural to think of those requirements as separate layers: a human presentation layer and a machine knowledge layer.
The distinction was useful.
It also turned out to be less clean than it sounded.
6.1 Two Consumers
Consider a camera retailer publishing information about a new camera.
A potential buyer may want to know its weight, sensor resolution, lens mount, video capabilities, battery life, and price. Those are factual questions.
The buyer may also want help deciding whether the camera is a good choice for wildlife photography, whether it balances well with a large telephoto lens, or whether switching to its lens system would be worth the expense.
Those are different information needs.
Some are answered well by specifications. Others require explanation, comparison, experience, or judgment.
An answer engine may encounter the same page with yet another task. A customer might ask for full-frame cameras weighing less than 700 grams with in-body stabilization and 4K/120 video. The system may need only a small portion of everything the retailer has published about each camera.
The retailer is therefore communicating with two consumers.
One may experience the publication as a document.
The other may use pieces of its knowledge as inputs to another information product.
That does not mean the underlying knowledge changes.
If the camera weighs 658 grams, it weighs 658 grams whether the value appears in a buying guide, a specification table, a comparison interface, or a generated answer.
What changes is what the consumer needs to do with it.
This was the original idea behind what we began calling the Two-Layer Web. Human communication and machine knowledge represented two different publishing requirements operating over the same underlying reality.
The obvious response would have been to build two representations: one for the person and another for the machine.
Production work eventually made that distinction much less obvious.
6.2 The Knowledge Model Changes the Human Page
Something unexpected happens when a publisher stops beginning with the page and starts with the knowledge.
The publisher has to decide what it actually knows.
For a camera, that means separating specifications from explanation, identifying which facts describe which model or configuration, deciding which conditions matter, establishing relationships to lenses or accessories, and determining which information is authoritative.
Those decisions are necessary if the knowledge is going to be useful to machines.
They can also improve the human publication.
Suppose a publisher has six paragraphs describing a camera’s recording capabilities. Some of that prose may be useful explanation. But perhaps much of it is simply carrying facts that would be easier to understand in a table:
| Video mode | Maximum frame rate |
|---|---|
| 8K | 30 fps |
| 4K | 120 fps |
| Full HD | 240 fps |
The table is not “machine content.”
It may simply be the clearest representation of that knowledge.
A person can scan it quickly. Two cameras can be compared more easily. On a mobile device, the reader does not need to hunt through several paragraphs for three specifications. The structure makes the relationship among the values visible.
Lists can have the same effect. If a camera supports five recording formats, a list may communicate that set more clearly than a paragraph containing five clauses.
Headings can separate costs, specifications, compatibility, and performance instead of requiring prose to continually reestablish what the reader is looking at.
Links can connect a camera to compatible lenses rather than requiring every relationship to be explained repeatedly.
Prose remains valuable where explanation is actually required.
The result is not a less human page.
In many cases, it is a simpler one.
This became an important consequence of thinking in Knowledge Objects. Asking what the publisher knows forces a distinction between knowledge that needs explanation and knowledge that mainly needs clear organization.
Traditional content production can blur the two because prose is often the default publishing material. Once the knowledge is modeled first, prose becomes one representational choice among several.
Sometimes it is the best one.
Sometimes a table is better.
Sometimes a list is better.
Sometimes a link says exactly what needs to be said.
The machine-facing problem had forced us to become more deliberate about human communication too.
6.3 Two Requirements, Not Necessarily Two Artifacts
This observation changed what we meant by the Two-Layer Web.
The distinction between the consumers remained useful. The assumption that each consumer required a separate artifact did not.
A well-constructed table can serve a person and a machine at the same time. The person sees an efficient comparison surface. The machine encounters regular relationships among labels and values.
A section can give a reader a clear visual division while also keeping related knowledge together.
A heading can tell both consumers what the following material concerns.
A link can help a reader navigate while connecting one addressable resource to another.
A date can communicate something useful to a person while preserving an important temporal distinction.
And prose can serve both when the knowledge itself is explanatory.
None of this requires the human document to become a database dump.
Nor does it imply that every piece of machine-useful knowledge belongs visibly on a page.
It means only that the distinction between human communication and machine knowledge does not map neatly onto a distinction between human files and machine files.
Sometimes the best representation is already useful to both.
That led us toward a more useful interpretation of the Two-Layer Web.
The two layers describe two consumption requirements over one body of knowledge.
How many technical representations are required is a separate question.
This matters because it changes the publisher’s objective. Instead of asking how to build a human page and then bolt a machine representation onto it, the publisher can ask how the underlying knowledge should be represented in the first place.
Some answers will improve both sides.
6.4 Model Meaning Before Rendering It
By this point, we had accumulated enough requirements that implementation became tempting.
We knew that the Question Space was larger than the Knowledge Space. We knew that useful knowledge carried more meaning than isolated data. We had given that knowledge a semantic boundary. And the Plan-ID problem had shown that the conditions governing valid application belonged to the knowledge as well.
Now we had two consumers.
It would have been easy to choose a technical format and start building.
But the Two-Layer work suggested that this was the wrong order.
A table might be the right representation for one body of knowledge. A paragraph might be right for another. Some meaning might already be expressed adequately by ordinary Web structures. Other meaning might require something more explicit.
We could not know which until we understood the knowledge we were trying to represent.
So the sequence became:
Model meaning before rendering it.
This was more than a machine-facing principle. It changed how we thought about the page itself.
Instead of beginning with “we need an article,” “we need an FAQ,” or “we need structured data,” we could begin with what the publisher actually knew. Once that knowledge was coherent, we could decide which parts needed explanation, which were naturally tabular, which formed collections, which depended on relationships, and which required additional structure.
The page became a rendering of the knowledge rather than the place where the knowledge had to be invented.
That left us at the end of Part I with a surprisingly concrete problem.
We had derived the need for a Knowledge Object. We understood what it needed to preserve. We knew that it had to remain useful across human and machine consumption.
What we did not yet have was an architecture for building one.
That is where Part II begins.