By this point, a KNOL has acquired several forms of expression.
Native HTML can give the Knowledge Object a visible structure. Semantic annotation can make selected meanings more explicit when the document structure alone does not say enough. Subjects, properties, values, and relationships can be represented without abandoning the human-readable page.
A public resource, however, does not exist by itself.
The page has an identity. The thing described by the page may have another. The page may contain significant sections, tables, or other resources that have useful identities of their own. The Primary Subject may relate to organizations, places, products, people, datasets, or other resources elsewhere on the Web.
Once those distinctions matter, the publisher needs more than a mechanism for expressing an assertion.
It needs a vocabulary for describing recognizable things on the public Web.
That is the role Schema.org can play within KNOL.
10.1 The Page Is Not the Thing
Consider a camera resource published at:
/cameras/apex-x5-mark-ii/
It is tempting to think of the URL and the camera as a single thing. In ordinary conversation, we might even say that the URL “is the camera page.”
Architecturally, however, two things are involved.
One is the webpage.
The other is the Apex X5 Mark II.
The distinction becomes obvious when we consider what can be said about each.
The webpage can have a publication date. It can have an author or publisher. It can be modified. It can contain sections, tables, images, and links.
The camera has none of those properties merely because a webpage about it does.
The camera has a manufacturer. It has a weight, sensor, lens mount, and video capabilities. It may have a model number and relationships to compatible products.
Those are not properties of the webpage.
The same distinction appears in Medicare publishing. A webpage may describe Medicare Plan H5590-010-0. The page can be updated on September 12. That does not mean the Medicare plan was updated on September 12. The publication changed. The thing being described did not necessarily change with it.
This seems elementary until both identities are represented inside the same publishing system.
KNOL already gives us the Primary Subject. The Knowledge Object can be principally about the Apex X5 Mark II while remaining distinct from the document through which that knowledge is published.
Schema.org gives us familiar vocabulary for preserving that distinction publicly.
The document can be described as a WebPage. Where an appropriate Schema.org type exists, the camera or another Primary Subject can be described according to what it actually is.
The value is not in the names themselves. It is in refusing to collapse the publication and its subject into one undifferentiated object.
That becomes increasingly important as more resources participate in the Knowledge Object.
10.2 Vocabulary for the Public Resource Environment
Chapter 9 introduced RDFa and Microdata as mechanisms through which selected meaning can be made explicit in HTML.
Schema.org serves a different purpose.
It provides vocabulary.
Types such as WebPage, Organization, Person, Place, Product, Dataset, Table, and WebPageElement give publishers recognizable terms for describing things that may participate in a public resource environment. Schema.org also provides properties through which many of those things can be related.
The distinction between mechanism and vocabulary matters.
RDFa can provide a way to state that one resource has a particular relationship to another. Microdata can associate properties with an identifiable item. JSON-LD can represent a graph separately from the visible document.
Schema.org can supply some of the public terms used in those statements.
KNOL does not depend on any particular combination.
The architectural question is whether the vocabulary accurately describes something the publisher is actually publishing.
A camera KNOL provides a simple example.
Conceptually, its public environment might contain:
WebPage
│
└── describes
│
▼
Apex X5 Mark II
│
├── Manufacturer
│
└── Lens MountThe WebPage is the publication resource.
The camera is its Primary Subject.
The manufacturer and lens mount are related things with identities of their own.
The same page may contain resources within the document that are worth identifying separately. A substantial specifications table, for example, may be useful as an identifiable structured surface. A significant Knowledge Aspect may have a stable fragment address within the page. A separately published collection of underlying data may genuinely constitute a dataset.
Those distinctions can produce a richer public environment:
WebPage
│
├── Primary Subject
│ ├── Manufacturer
│ └── Lens Mount
│
├── Specifications Aspect
│ └── Specifications Table
│
└── Published DatasetNot every KNOL needs all of those resources.
A Knowledge Aspect does not need to become a WebPageElement merely because it exists. An ordinary HTML table does not need another identity simply because Schema.org has a Table type. Structured information does not become a Dataset merely because it contains data.
The vocabulary becomes useful when the distinction is real.
A separately identifiable dataset may have provenance, distributions, temporal scope, or a lifecycle of its own. That makes it materially different from a table displaying a projection of some of its data.
Likewise, an addressable section may deserve recognition as a public resource when other resources need to refer to it, when it participates independently in provenance, or when identifying it clarifies the architecture of the publication.
Schema.org therefore does not provide a checklist of nodes that every KNOL should create.
It gives the publisher a public vocabulary that can be used where the vocabulary corresponds honestly to the resources that actually exist.
10.3 Building the Public Resource Graph
Once those resources have identities, their relationships begin to form a graph.
The word graph can make this sound more elaborate than it needs to be.
Consider again a Medicare plan resource.
The page is one resource.
The Medicare plan is another.
The plan may be offered by an organization. It belongs to a contract. A Benefits section may be significant enough to have its own stable address within the page. That section may contain a substantial benefits table. A separately published data manifestation may exist elsewhere.
Conceptually, the environment might look like this:
WebPage
│
├── Primary Subject: Medicare Plan
│ │
│ ├── Carrier / Organization
│ │
│ └── Contract
│
├── Benefits Aspect
│ │
│ └── Benefits Table
│
└── Published DatasetThere is nothing inherently valuable about adding more nodes to this diagram.
The value comes from preserving distinctions that already exist.
The page is not the plan.
The plan is not the contract.
The carrier is not merely a string appearing beside the plan name.
The Benefits section is not the entire document.
The benefits table is not necessarily the dataset from which its values were produced.
Once those distinctions have stable public identities, the publisher can describe and relate them without repeatedly collapsing them back into the page.
This also allows the public resource graph to remain closely aligned with the human document.
A section that has a stable fragment identifier can be addressed directly. A significant table can have a stable identifier within that section. A link in the human document can lead to another resource whose identity is also represented in the graph.
The graph is therefore not a second semantic world hidden behind the page.
It describes the publication that actually exists.
That restraint matters.
It is easy to produce elaborate structured-data graphs containing nodes that have little correspondence to anything a person could recognize in the published resource. Technically, those graphs may be perfectly parseable. Architecturally, they can become another independent representation that publishers must understand and maintain.
KNOL gives us a different reason to build the graph.
The graph exists when public identity helps preserve the architecture of the knowledge.
A simple Knowledge Object may need very little.
A complex resource may justify considerably more.
The number of nodes is irrelevant.
What matters is whether each node represents a real and useful distinction in what the publisher has published.
10.4 Vocabulary Has a Boundary Too
Once a publisher has modeled a rich Knowledge Object, Schema.org can become tempting.
The publisher knows what it wants to say. The vocabulary contains thousands of types and properties. When an exact term does not appear to exist, something nearby often looks almost suitable.
That is where the publisher needs to stop.
Schema.org does not define what the publisher is allowed to know.
It describes the things its vocabulary knows how to describe.
Those are different responsibilities.
Suppose a publisher has modeled a resolution condition stating that a value cannot safely be applied until a geographic discriminator is known. That condition is meaningful knowledge. If Schema.org does not provide an accurate vocabulary for expressing it, choosing an unrelated property does not improve the Knowledge Object.
It makes the public assertion less accurate.
The same problem appears with types.
A specialized Knowledge Aspect does not become a Dataset because Dataset is the nearest recognizable Schema.org type. A contextual state does not become a Place merely because geography participates in its identity. A thing should not be given a type simply because the resulting graph is easier to validate.
Syntactic validity and semantic accuracy are not the same thing.
We encountered this boundary directly while considering whether KNOL protocol conformance could be represented through Schema.org.
The conformsTo property initially appeared promising. The idea itself was reasonable: a publisher might want to state that a resource conformed to a defined protocol.
The difficulty appeared when we tried to model the complete assertion. We could not identify a Schema.org item that honestly represented the thing making the conformance assertion in the way the architecture required.
We could have chosen the nearest available type and made the graph work.
That would have solved the serialization problem by weakening the meaning.
So we did not use it.
The episode provided a useful reminder that a vocabulary has boundaries just as HTML does.
When HTML reaches its boundary, semantic annotation can make additional meaning explicit.
When a public vocabulary reaches its boundary, the correct response is not necessarily another approximation.
Sometimes the vocabulary simply does not have the term the publisher needs.
That does not invalidate the knowledge.
It tells us where the vocabulary stops.
KNOL therefore uses Schema.org where Schema.org accurately describes the public resources and relationships surrounding the Knowledge Object. It does not require the Knowledge Object to fit completely inside that vocabulary.
The sequence remains the same one that has guided the architecture from the beginning.
The publisher determines what it knows. The Knowledge Object preserves the semantic boundary. HTML gives much of that knowledge native document structure. Semantic annotation can make selected meaning explicit. Schema.org can provide recognizable public vocabulary where that vocabulary fits.
Each solves a different problem.
Keeping those responsibilities separate lets the publisher use Schema.org for what it does well without asking it to define the knowledge itself.