Native HTML carried the Knowledge Object farther than we initially expected.
A document could establish a principal boundary, organize knowledge into coherent aspects, preserve hierarchy, represent comparisons through tables, define concepts, express collections, connect addressable resources, identify temporal values, and retain explanation where explanation was the appropriate form.
That was a substantial amount of knowledge architecture using nothing more than the existing Web.
But Chapter 8 also exposed an honest limit.
A link can tell us that two resources are connected without telling us precisely how they are related. A table can associate a label with a value without formally identifying the property represented by that value. A section can keep related assertions together without identifying the subject of every assertion inside it.
The human reader may understand those distinctions from language and context.
The publisher certainly understands them.
Sometimes the distinction matters enough that leaving it implicit creates exactly the kind of inference problem we have been trying to reduce.
That is where semantic annotation becomes useful.
9.1 The Meaning HTML Leaves Implicit
Return to the Apex X5 Mark II.
The camera’s Compatibility section might contain a simple sentence:
The Apex X5 Mark II uses the Apex Z lens mount.
The words Apex Z lens mount may link to another public resource describing that mount.
For a human reader, very little is ambiguous. The sentence explains the relationship and the link provides a way to learn more.
The document also contains useful native structure. The relationship appears within the Compatibility aspect of the camera’s Knowledge Object. The related concept has its own address.
But the publisher knows something more precise than the link itself expresses.
Conceptually, the publisher knows:
Apex X5 Mark II → uses lens mount → Apex Z
That relationship is part of the publisher’s knowledge.
The difference becomes more consequential when the subject itself changes.
Chapter 7 introduced the example of a Medicare plan KNOL whose Primary Subject is Plan H5590-010-0. Most of the assertions within the resource describe the plan. Its costs belong to the plan. Its benefits belong to the plan. Its availability belongs to the plan.
Performance information may be different.
If the performance rating is reported at the contract level, then the publisher knows that the rating describes Contract H5590 rather than Plan H5590-010-0.
A human page can communicate that distinction perfectly well:
Performance ratings for this plan are reported at the contract level.
The Performance section can link to the contract. Its heading and surrounding prose can make the relationship understandable.
But the Knowledge Object contains a more precise distinction:
KNOL Primary Subject
Plan H5590-010-0
↓ belongs to
Contract H5590
│
└── Performance RatingThe document is still about the plan.
The performance assertion is about the contract.
That distinction matters because a fact can change meaning when it becomes attached to the wrong subject. A contract-level rating presented as though it were a plan-level rating may remain numerically accurate while becoming semantically inaccurate.
This is not a failure of HTML.
HTML has already done its job. It has structured the document and helped communicate the distinction to the human reader.
The remaining problem is more specific.
The publisher knows meaning that the document structure leaves implicit.
Semantic annotation gives the publisher a way to make selected parts of that meaning more explicit without replacing the document that already works.
9.2 Subject, Property, Value—and Relationship
Many factual assertions can be reduced conceptually to a simple pattern:
Subject → Property → Value
For example:
Apex X5 Mark II → body weight → 658 g
The value alone is not the assertion.
Even body weight = 658 g remains incomplete unless we know whose body weight is being described.
The subject matters.
So does the property.
And in some cases, so do details about the value itself. A human reader may see $18, while a machine-facing representation may benefit from knowing that the underlying value is numeric, represents currency, and has a canonical value independent of its display formatting.
Relationships follow a similar pattern:
Subject → Relationship → Object
For example:
Apex X5 Mark II → uses lens mount → Apex Z
or:
Plan H5590-010-0 → belongs to → Contract H5590
These are familiar ideas in semantic systems, and they predate KNOL by many years. Their importance here is practical rather than theoretical.
They give us a way to describe precisely what native document structure sometimes leaves dependent on interpretation.
This becomes especially useful inside a Knowledge Object because the subject of an individual assertion does not always match the KNOL’s Primary Subject.
The KNOL can remain about the Medicare plan while a particular assertion identifies the contract as its subject.
Nothing about the human document has to change.
The reader can remain on the plan page. The Performance section can remain where it is useful. The explanation can remain understandable prose.
The semantic representation simply preserves something the publisher already knows:
This particular assertion is about the contract.
The same approach can clarify relationships. A hyperlink can remain a hyperlink for the person while additional semantics identify what kind of relationship connects the two resources.
A displayed value can remain natural for the human reader while its underlying value is represented more precisely where that precision matters.
The objective is not to translate the entire page into formal statements.
It is to preserve distinctions that matter when the knowledge is used outside the immediate reading experience.
9.3 Existing Mechanisms, Not a KNOL Language
Once we encountered the limits of native HTML, it would have been easy to invent KNOL-specific syntax for filling the gaps.
There was little reason to do so.
The Web already has established mechanisms for attaching semantic information to content within an HTML document. Two of them are Microdata and RDFa.
Both can associate visible information with subjects, properties, identifiers, types, values, and relationships. They approach that work differently, but either can be useful depending on the knowledge being represented.
Microdata often fits comfortably when the semantic structure follows the hierarchy of the document. An identifiable item contains properties, and those properties may contain other items.
RDFa can be particularly useful when the semantic structure is less closely aligned with document containment. It can identify subjects and relationships more directly, which becomes helpful when a KNOL contains several related subjects or when an assertion temporarily changes from the Primary Subject to another entity.
The distinction is visible in the Medicare example.
The page may remain structurally organized around Plan H5590-010-0 while semantic annotation identifies Contract H5590 as the subject of the performance assertion.
The important point is not which annotation mechanism wins.
KNOL requires neither RDFa nor Microdata.
They are mechanisms through which selected meaning can be made more explicit. They are not the Knowledge Object and they do not define its architecture.
A publisher with a straightforward object may find Microdata entirely adequate. Another may prefer RDFa because its knowledge contains more subject switching or graph-like relationships. Some parts of a KNOL may need no additional annotation at all.
The architecture remains the same.
The publisher models the knowledge first and then chooses a mechanism capable of expressing whatever important meaning remains implicit.
This keeps KNOL agnostic about syntax.
It also keeps the architecture from becoming dependent on a particular generation of machine consumers. We do not know which semantic mechanisms every future crawler, model, agent, or answer engine will use. Different systems may consume the same public artifact differently.
What the publisher can control is whether the artifact remains coherent and whether important meaning has been represented faithfully.
If a consumer uses only the visible document, the document should still work.
If it recognizes native HTML structure, more organization becomes available.
If it also recognizes semantic annotation, additional meaning may become explicit.
The Knowledge Object does not depend on any one of those capabilities to exist.
9.4 Annotate Meaning, Not Markup
Once semantic annotation becomes available, there is an obvious temptation to use it everywhere.
That misses the point.
A table does not become more tabular because every cell receives another semantic label. A list does not need additional annotation merely to establish that its items form a collection. A paragraph does not become better knowledge because every phrase has been decomposed into formal properties.
Native HTML already communicates useful meaning.
Semantic annotation earns its place when something important would otherwise remain ambiguous, be lost when extracted, or depend unnecessarily on inference.
Subject identity is one example.
If an assertion concerns the contract rather than the KNOL’s Primary Subject, preserving that distinction can prevent the fact from drifting onto the wrong entity.
Relationships provide another.
A link already establishes a connection. Additional semantics may be useful when the difference between uses mount, offered by, variant of, or located in matters to the knowledge.
Values can create another need. A person may prefer to see $18, 4 stars, or 15.26%. Where necessary, semantic annotation can preserve a canonical value or datatype without making the human presentation less natural.
The common question is therefore not how much annotation a KNOL should contain.
It is:
What meaning are we trying to preserve?
That question also imposes restraint.
Explicit semantics can make an assertion appear unusually precise. The underlying knowledge must justify that precision.
If a performance rating belongs to a contract, identifying it as a plan-level property because that produces simpler markup would make the representation less accurate.
If a value is derived from authoritative source data, semantic precision should not obscure the distinction between the source assertion and the publisher’s derivation.
If a fact applies only within a particular context, annotation should not silently broaden the boundary of valid assertion.
Semantic annotation should make the publisher’s knowledge more faithful.
It should not make the publisher appear to know more than it does.
This is the same discipline we have applied throughout the book. Model the knowledge first. Use native structure where it honestly represents that knowledge. Add explicit semantics where an important distinction remains.
The result is not a page covered with machine markup.
It is a Knowledge Object whose visible document remains useful to people while selected parts of its meaning can become more explicit to machines.
One question remains.
A semantic mechanism can tell us how to associate a subject with a property, value, or relationship.
It does not necessarily tell us what those subjects, properties, and relationships should be called.
That is a vocabulary problem.
And the public Web already has one unusually important vocabulary waiting for us.