Part I left us with a Knowledge Object but not yet an architecture for publishing one.
The path to that point began with answer engines, but the problem became progressively more fundamental. The Question Space was larger than the Knowledge Space beneath it. Machine-readable data needed enough meaning to remain useful outside the systems that created it. That meaning needed a semantic boundary. The Knowledge Object provided one. Resolution then showed that even valid facts had limits on how safely they could be applied.
The Two-Layer Web added another consideration. The same underlying knowledge increasingly served two consumers. Humans might need explanation, comparison, judgment, and an effective information experience. Machines might use portions of the same knowledge in filtering, comparison, retrieval, resolution, and synthesis.
The problem was no longer whether the Knowledge Object was useful.
It was how to publish one.
7.1 The Missing Publishing Abstraction
The Web already has an extensive technical vocabulary for publishing information.
URLs give resources addresses. HTML gives documents structure. Databases store and retrieve information. APIs expose it to applications. Formats such as JSON, XML, and CSV serialize it. Semantic technologies can make particular meanings more explicit. Knowledge graphs can represent entities and relationships.
None of these technologies was missing.
What was missing from our work was a level above them.
We needed a way to begin with the Knowledge Object itself and decide what the publisher was representing before deciding which technical mechanisms should carry it.
Consider a camera publisher preparing a resource for the Apex X5 Mark II. The publisher could begin by asking which Schema.org type fits the page, whether to use RDFa or Microdata, which database fields should populate the specification table, or what JSON should be generated for machines.
Those may all become legitimate implementation questions.
They do not establish what the publisher knows about the camera.
Before choosing a representation, the publisher needs to determine what the resource fundamentally represents, which knowledge belongs within its boundary, which assertions describe the camera itself, which describe related subjects, which relationships matter, and which conditions govern the use of those assertions.
Those are architectural decisions.
The distinction became important because starting with a technical representation can quietly allow that representation to determine the shape of the knowledge. A database encourages the publisher to think in records. A document encourages the publisher to think in pages and sections. A vocabulary encourages the publisher to think in the entities and properties that vocabulary already defines.
None of those perspectives is necessarily wrong.
But none should determine what the publisher knows simply because it happened to be selected first.
The Knowledge Object has to come first.
Only then can the publisher ask how the Web should express it.
That gave us a principle that would remain important as the architecture developed:
Architecture precedes syntax.
The markup is not the architecture.
It is an expression of the architecture.
7.2 KNOL — Knowledge-Native Object Layer
We call that architecture KNOL: the Knowledge-Native Object Layer.
KNOL is a publisher-side architecture for representing and publishing a Knowledge Object through the existing Web for human and machine knowledge.
The important word is knowledge-native.
Traditional web publishing usually begins with a document. The publisher decides that a page, article, product resource, comparison, or other content artifact needs to exist and then assembles information within it. Additional structure may be added later to improve search visibility, accessibility, machine interpretation, or application behavior.
KNOL reverses the starting point.
It begins with what the publisher knows.
The publisher establishes the Knowledge Object first: what it represents, what belongs within its semantic boundary, what is asserted, and what meaning must remain attached to those assertions.
The page can then become a representation of that knowledge.
This does not diminish the page. Chapter 6 showed why thinking carefully about knowledge can improve human publishing rather than compete with it. Once a publisher distinguishes facts from explanation and identifies the natural structure of what is being communicated, a table may become preferable to several paragraphs, a list may become clearer than a sentence containing six items, and explanatory prose can concentrate on the things that genuinely require explanation.
KNOL therefore does not begin by asking how to create a separate machine version of a human page.
It asks a different question:
How should this Knowledge Object be expressed through the Web?
Sometimes one representation may serve both consumers remarkably well. Sometimes important meaning may need to be made more explicit. Sometimes additional representations may be justified.
Those decisions come later.
The architectural reversal comes first.
In a document-native model, the page tends to become the organizing object and knowledge is reconstructed from what the page contains.
In a knowledge-native model, the Knowledge Object is the organizing object and the page becomes one way that knowledge can be expressed.
That is what KNOL changes.
It does not introduce another file type beside the webpage.
It changes what the publisher considers itself to be publishing.
7.3 The Architecture of a KNOL
A KNOL gives architectural form to the Knowledge Object developed in Part I.
Consider again the Apex X5 Mark II.
The publisher may know its identity, specifications, video capabilities, compatibility, availability, and provenance. Those are not six unrelated collections of information. They are coherent aspects of what the publisher knows about one camera.
Conceptually, the object might look like this:
Apex X5 Mark II
Primary Subject
│
├── Identity
├── Specifications
├── Video
├── Compatibility
├── Availability
└── ProvenanceThe Primary Subject establishes what the KNOL is fundamentally about.
In this case, the answer is straightforward: the Apex X5 Mark II.
That sounds almost too obvious to deserve architectural status. On real publishing resources, however, the distinction becomes important quickly. A page about a camera may mention its manufacturer, lens mount, compatible accessories, predecessor, warranty provider, and competing products. All of those things may be relevant to the page without becoming the thing the Knowledge Object principally represents.
The Primary Subject anchors the boundary.
Within that boundary, Knowledge Aspects organize coherent dimensions of what the publisher knows.
Specifications belong together for a reason different from compatibility information. Availability describes another aspect of the product. Provenance answers another class of questions about the knowledge itself.
The aspects give the object internal structure without breaking it into unrelated pieces.
Within those aspects are assertions.
The camera weighs a particular amount. It uses a particular lens mount. It supports particular video modes. It has particular dimensions.
Those assertions are the factual substance of the object, but the lessons of Part I still apply to them. Their subjects must remain identifiable. Relevant context must remain attached. Relationships may connect them to other things. Provenance may establish their authority. Some assertions may depend on conditions that determine when they can safely be applied.
The architecture can therefore be understood at a high level as:
KNOL
│
├── Primary Subject
│
├── Knowledge Aspects
│ └── Assertions
│
├── Relationships
├── Context
├── Provenance
└── Resolution ConditionsThis is not intended as a rigid container into which every domain must be forced.
A camera KNOL will not contain the same knowledge as a Medicare plan KNOL. A facility will differ from a product. A county-level coverage environment may be organized around geography and time rather than a conventional product entity.
What remains stable is the architectural question underneath them:
What does this Knowledge Object represent, and what meaning must remain intact for what the publisher knows to remain coherent?
Chapter 4 described this as a semantic contract.
KNOL gives that contract architectural form.
The Primary Subject establishes the center. Knowledge Aspects organize the object. Assertions state what is known. Relationships connect that knowledge to other things. Context establishes conditions under which assertions retain their intended meaning. Provenance preserves their authority and lineage. Resolution conditions preserve limits on their valid application.
The architecture follows the knowledge.
The knowledge does not exist to satisfy the architecture.
7.4 One Object, More Than One Subject
The Primary Subject creates an important distinction that is easy to miss.
A KNOL is principally about one subject or coherent state.
That does not mean every assertion inside the KNOL must be about that Primary Subject.
Consider the Apex X5 Mark II again.
The camera may be the Primary Subject, but a relationship can connect it to its manufacturer. Another can connect it to a lens mount. Warranty information may involve the organization responsible for the warranty. Compatibility knowledge may involve both the camera and another product.
Those related subjects do not become the camera merely because their information appears within the camera’s Knowledge Object.
Medicare makes the distinction even clearer.
Suppose a KNOL represents:
Medicare Plan H5590-010-0
The plan is the Primary Subject.
Most of the knowledge inside the object may describe that plan: its identity, costs, benefits, availability, prescription drug coverage, and contact information.
The same resource may also contain performance information.
But the performance rating may not actually be an assertion about Plan H5590-010-0. It may describe the CMS contract H5590, under which the plan exists.
The distinction matters.
If the publisher simply places the performance information on the plan page and relies on proximity to establish its subject, a consuming system may reasonably associate the rating with the plan itself.
The publisher knows something more precise.
It knows that the Knowledge Object is principally about the plan while that particular assertion concerns the contract.
KNOL needs to preserve both facts.
Conceptually:
KNOL
Primary Subject: Plan H5590-010-0
│
├── Costs
│ └── assertions about Plan H5590-010-0
│
├── Benefits
│ └── assertions about Plan H5590-010-0
│
└── Performance
└── assertions about Contract H5590This distinction is one reason the Knowledge Object cannot simply be treated as a structured entity record.
The semantic boundary tells us what coherent knowledge belongs together.
It does not erase the identities of the things represented inside that boundary.
A publisher may know that one assertion concerns the Primary Subject, another concerns a parent organization, and another expresses a relationship between two subjects. If those distinctions matter to the meaning of the knowledge, the architecture should preserve them.
This gives KNOL two levels of identity that should not be confused.
The Primary Subject tells us what the Knowledge Object is fundamentally about.
The assertion subject tells us what a particular assertion actually describes.
Sometimes they are the same.
Sometimes they are not.
The distinction becomes especially important when knowledge is retrieved in pieces. An assertion removed from its surrounding document should not silently change subjects merely because the page from which it came was about something else.
The publisher already knows whose fact it is.
KNOL provides a place for that distinction to survive.
7.5 What KNOL Changes
KNOL enters a Web that already has mature publishing technologies.
It is not intended to replace them.
HTML, semantic annotation, established vocabularies, databases, APIs, knowledge graphs, and other technologies can all participate in publishing knowledge. WebMEM®, which emerged earlier in the production work behind this book, can also provide deeper structured manifestations when a Knowledge Object contains machine-oriented state that does not belong comfortably in the visible document.
KNOL operates at a different level.
It defines the Knowledge Object those technologies may help express.
That distinction matters because otherwise KNOL can easily be mistaken for another structured-data vocabulary or markup proposal. It is neither.
A publisher could reproduce a particular markup pattern perfectly and still fail to construct a coherent KNOL if the semantic boundary was wrong, assertions were attached to the wrong subjects, context was missing, or resolution conditions were ignored.
Conversely, a simple Knowledge Object may require very little technical machinery if the existing Web already provides structures that represent its knowledge honestly.
The architecture therefore does not depend on predicting which parser, answer engine, model, crawler, or machine interface will dominate.
The publisher’s durable asset is the knowledge itself.
KNOL gives that knowledge a publishable architecture.
This brings us to a question that initially appeared much more technical than it turned out to be.
Once we had defined the Knowledge Object, we expected that making it real on the public Web might require increasingly specialized machine-facing representations.
Instead, production work kept directing our attention back toward technology the Web had possessed all along.
HTML.
Not merely as the container into which a page is poured, but as a language already capable of expressing boundaries, hierarchy, collections, relationships, tabular structures, time, and explanation.
The architecture had been new to us.
Many of the primitives were not.