Semantic Data Templates: Publishing Page-Level Machine Knowledge

Publishing Page-Level Knowledge Alongside Human-Facing Content

The WebMEM Protocol requires a machine-facing representation capable of preserving the knowledge associated with a web resource without forcing that knowledge into the structure of the human-facing document.

This is the role of the Semantic Data Template (SDT).

An SDT is the page-level machine-facing representation of the knowledge a publisher chooses to expose through a web resource.

It provides a semantic composition boundary within which WebMEM Fragments, assertions, identities, provenance, relationships, applicability, and other knowledge structures can be represented coherently.

Conceptually:

Web Resource
│
├── Human-Facing Representation
│   ├── prose
│   ├── tables
│   ├── charts
│   ├── navigation
│   └── interaction
│
└── Machine-Facing Representation
    └── Semantic Data Template
        ├── Fragment
        ├── Fragment
        ├── Fragment
        └── Fragment

The human-facing representation and the SDT describe the same underlying information environment.

They are not required to use the same structure.

The human representation is organized for human understanding. The SDT is organized for semantic recoverability.

4.1 The Evolution of the Semantic Data Template

The original 2025 framework described Semantic Data Templates primarily as a binding mechanism between visible page elements and external Semantic Digests.

Under that model:

Visible Content Atom
        ↓
data-* Semantic Binding
        ↓
Semantic Digest
        ↓
Machine Representation

For example, a visible premium might carry attributes identifying its term, value, source, type, and corresponding Digest endpoint.

That architecture established an important principle: machine-facing semantics can coexist directly with ordinary HTML without changing the visible user experience.

But production implementation revealed that binding every visible content atom to an external machine object created unnecessary coupling between two representations designed for different interpreters.

The human DOM may change because of:

responsive design;
editorial changes;
table redesign;
component systems;
accessibility requirements;
interactive interfaces;
personalization;
or ordinary presentation changes.

The underlying knowledge may remain unchanged.

The current WebMEM architecture therefore separates human presentation from machine knowledge representation.

2025

Visible Content
        ↕
Semantic Anchor Bindings
        ↕
Semantic Digests


2026

Underlying Publisher Knowledge
        ↓
   ┌────┴────┐
   ↓         ↓
Human      Machine
View       Representation
             ↓
             SDT

The two representations remain semantically aligned without requiring one-to-one DOM bindings between them.

4.2 The SDT Is a Knowledge Representation

The SDT is not metadata describing the page.

It is not an annotation layer placed over the page.

It is not an alternate visual presentation.

And it is not merely a container for arbitrary structured data.

The SDT represents the publisher’s machine-facing knowledge associated with the resource.

For example, a county-level Medicare resource may present human readers with:

Introduction

Coverage Explanation

Plan Tables

Premium Statistics

Carrier Information

Source Citations

The SDT associated with that resource might instead organize the knowledge as:

SDT
│
├── IdentityFragment
│   └── County Identity
│
├── IndexFragment
│   └── Available Plans
│
├── DataFragment
│   └── Source-Observed Market Facts
│
├── DerivedStatsFragment
│   └── Publisher-Derived Statistics
│
└── MetaFragment
    └── Source Dataset Information

Neither structure is a transformation of the other.

Both are representations of the same underlying information for different purposes.

4.3 SDT Identity

Every SDT requires an identifiable page-level scope.

Conceptually:

Web Resource
https://example.org/medicare-options/arizona/mohave-county/

SDT Identity
https://example.org/medicare-options/arizona/mohave-county/#webmem

The web resource and the SDT are related but distinct identifiable objects.

The resource is the published page.

The SDT is the machine-facing knowledge representation associated with that resource.

This distinction allows other objects to reference the SDT without incorrectly treating the SDT, the page, and the entities described by the page as the same thing.

4.4 Dataset Declaration

The current WebMEM architecture uses Schema.org Dataset JSON-LD to declare the page-level machine dataset associated with the SDT.

Conceptually:

Schema.org Dataset
        ↓
Declares the machine dataset
        ↓
Shared Identity
        ↓
Semantic Data Template
        ↓
Represents the WebMEM knowledge

For example:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "@id": "https://example.org/resource/#webmem",
  "name": "Machine-readable knowledge for Example Resource",
  "url": "https://example.org/resource/"
}
</script>

The corresponding SDT may use the same identity:

<template
  data-webmem-sdt
  data-sdt-id="https://example.org/resource/#webmem">

  ...

</template>

The shared identity maps the external Dataset declaration to the internal WebMEM representation.

The distinction is important:

Dataset JSON-LD
→ declares the dataset

SDT
→ represents its WebMEM knowledge

WebMEM does not attempt to replace Schema.org where an established vocabulary already performs the required declaration function.

4.5 Fragment Composition

An SDT is composed of one or more WebMEM Fragments.

Each fragment has:

an identifiable fragment scope;
a declared Fragment Class;
the knowledge appropriate to that class;
and any identity, provenance, context, relationships, or other semantics required to interpret that knowledge correctly.

Conceptually:

SDT
│
├── Fragment A
│   ├── Fragment Identity
│   ├── Fragment Class
│   ├── Subject Identity
│   └── Knowledge
│
├── Fragment B
│   ├── Fragment Identity
│   ├── Fragment Class
│   └── Knowledge
│
└── Fragment C
    ├── Fragment Identity
    ├── Fragment Class
    └── Knowledge

The fragments are modular, but they are not isolated.

They may share entity identity, source context, geographic scope, temporal scope, or explicit relationships.

The SDT provides the composition boundary within which those objects form a coherent page-level representation.

4.6 Fragment Boundaries Preserve Meaning

Fragment boundaries should follow semantic responsibility rather than visual page layout.

A single human-facing table may contain knowledge that belongs to several fragments.

For example:

Human Table

Plan | Premium | Enrollment | Market Average

may draw from:

IndexFragment
→ plan membership

DataFragment
→ premium

DataFragment
→ enrollment

DerivedStatsFragment
→ market average

Conversely, one fragment may represent knowledge displayed in several different places on the human-facing page.

Fragment boundaries should preserve semantic meaning, not mirror presentation boundaries.

4.7 Assertions Within the SDT

Factual knowledge inside an SDT is represented through assertions associated with identifiable subjects.

For example:

Subject:
plan:H5521-290-0

Assertion:
plan_type = PPO

Assertion:
drug_coverage = true

or:

Subject:
segment:H5521-290-001

Assertion:
monthly_premium = 18.50 USD

Context:
plan_year = 2026

The SDT allows those assertions to retain context that might otherwise be communicated only through human presentation.

A machine should not need to infer that $18.50 is a premium, that the premium belongs to a particular segment, or that it applies to a particular year when the publisher already knows those facts.

4.8 Shared Context

An SDT may establish context shared by multiple fragments.

For example:

SDT Context

geography:
county:04015

plan_year:
2026

Fragments within the SDT may inherit that context where it applies.

A fragment may establish more specific context:

DataFragment

entity:
plan:H5521-290-0

source:
CMS PBP 2026

And an individual assertion may override part of that context:

enrollment

source:
CMS Monthly Enrollment

applicable_month:
2026-07

Conceptually:

SDT Context
        ↓
Fragment Context
        ↓
Sub-Structure Context
        ↓
Assertion Context

More-specific context overrides broader inherited context where necessary.

Context should be declared at the broadest level where it remains true—and no broader.

4.9 Provenance Within the SDT

An SDT may contain knowledge derived from several sources.

For example:

Plan Availability
→ CMS Landscape

Plan Benefits
→ CMS PBP

Enrollment
→ CMS Monthly Enrollment

Star Rating
→ CMS Performance Data

Average Premium
→ Publisher Derivation from CMS Landscape

The SDT does not flatten those lineages merely because the knowledge appears on one page.

Provenance may be shared at the fragment level where several assertions have the same lineage.

More-specific provenance may be attached where an assertion differs.

This allows the machine-facing representation to preserve the evidentiary structure the publisher’s internal systems already possess.

4.10 Relationships Within the SDT

Multiple entities may participate in one SDT.

For example:

County
Contract
Plan
Segment
Carrier
Formulary

Participation in the same SDT does not establish how those entities relate.

The relationships should be represented explicitly where they are material:

contract:H5521
→ hasPlan
→ plan:H5521-290

plan:H5521-290
→ hasSegment
→ segment:H5521-290-001

segment:H5521-290-001
→ appliesIn
→ county:04015

This is another reason the SDT cannot simply be a flat block of page metadata.

It represents an information structure.

4.11 The SDT and Resolution

SDT composition becomes especially important when machines must traverse multiple kinds of knowledge before determining what applies.

For example:

County
→ IndexFragment
→ Available Plans
→ Plan Identity
→ Geographic Segment
→ DataFragment
→ Applicable Benefit

or:

Contract ID
→ IdentityFragment
→ Contract
→ Related Plans
→ Canonical Plan Resources

The SDT does not execute these paths.

It preserves the identities, relationships, context, and knowledge required for the paths to exist explicitly.

A consuming system may use that structure as part of its own resolution process.

4.12 HTML-in-HTML Serialization

Under the current WebMEM serialization, the SDT is published within an inert HTML <template> container.

A simplified resource may resemble:

<main>

  <h1>Human-Facing Resource</h1>

  <p>
    Content designed for human readers.
  </p>

</main>


<template
  data-webmem-sdt
  data-sdt-id="https://example.org/resource/#webmem"
  data-plan-year="2026">

  <template
    data-webmem-fragment
    data-fragment-class="IdentityFragment"
    data-fragment-id="entity-identity"
    data-entity-id="plan:H5521-290-0">

    ...

  </template>


  <template
    data-webmem-fragment
    data-fragment-class="DataFragment"
    data-fragment-id="plan-benefits"
    data-entity-id="plan:H5521-290-0">

    <data
      data-webmem-assertion
      data-field="plan_type"
      value="ppo"
      data-type="enumerated">
      PPO
    </data>

  </template>

</template>

The <template> contents are present in the HTML document but are not rendered as ordinary visible page content.

This allows the human-facing and machine-facing representations to coexist within the same canonical resource.

4.13 From Semantic Anchor Layer to Parallel Representation

The original framework described a Semantic Anchor Layer: an invisible metadata overlay attached directly to visible HTML elements.

The intent was to connect what humans saw with corresponding machine knowledge at fragment-level precision.

The current architecture preserves the goal of semantic alignment but removes the requirement for pervasive visible-DOM annotation.

Instead:

Underlying Knowledge
        ↓
   ┌────┴────┐
   ↓         ↓
Human      SDT
Representation
   ↓         ↓
Human      Machine
Interpretation

The representations remain aligned through shared underlying facts, identities, provenance, relationships, and publishing logic.

They do not require a one-to-one attribute binding between every visible value and every machine assertion.

This has several advantages:

human presentation can evolve without rewriting the knowledge model;
machine knowledge can be organized semantically rather than visually;
responsive and interactive interfaces do not alter machine semantics;
one machine fragment can represent knowledge displayed in several human locations;
one human component can draw from several machine knowledge objects;
and both representations can be generated from the same underlying publisher data.

The binding is now semantic rather than DOM-dependent.

4.14 Dual Publishing Does Not Mean Duplicate Publishing

Two-tier publishing does not require publishers to maintain two independent versions of their knowledge manually.

Ideally, both representations are produced from the same underlying information system.

Publisher Data / Knowledge
        ↓
   ┌────┴────┐
   ↓         ↓
Human      WebMEM
Templates   Serialization
   ↓         ↓
Human      Machine
Page       Knowledge

For a data-driven publishing system, the same source record might generate:

Human:
"$18.50 monthly premium"

Machine:
monthly_premium = 18.50 USD

The output differs.

The underlying knowledge does not.

This is important because manually maintained parallel representations create a new risk: semantic drift.

4.15 Semantic Alignment

The human-facing representation and the SDT should not materially contradict one another.

If the human page states:

Monthly Premium:
$18.50

while the SDT asserts:

monthly_premium = 32.00 USD

the resource contains a semantic alignment failure unless the difference is explicitly explained by identity, scope, time, or another material context.

Alignment does not require identical text.

For example:

Human:
"No monthly premium"

Machine:
monthly_premium = 0 USD

These representations are semantically aligned even though their surface language differs.

Likewise:

Human:
"Available in Mohave County"

Machine:
plan:H5521-290-0
→ availableIn
→ county:04015

expresses the same underlying relationship in forms appropriate to different interpreters.

The objective is semantic equivalence where the two representations describe the same knowledge—not textual duplication.

4.16 The SDT May Contain Knowledge Not Repeated Visibly

The SDT is not limited to facts that appear verbatim in visible page content.

A publisher may possess semantic structure necessary to interpret visible knowledge correctly even though that structure would add little value if repeated as human-facing prose.

For example, the human page may display:

Example PPO
$18.50 monthly premium

while the SDT additionally preserves:

plan:H5521-290
→ hasSegment
→ segment:H5521-290-001

segment:H5521-290-001
→ appliesIn
→ county:04015

segment:H5521-290-001
→ monthly_premium
→ 18.50 USD

premium assertion
→ sourcedFrom
→ CMS PBP 2026

The human reader may not need to see every identifier and relationship.

The machine-facing representation may need them to preserve the meaning of the displayed value outside its presentation context.

This is not hidden content in the conventional sense of placing unrelated material where users cannot see it.

It is an alternate representation of publisher-known knowledge associated with the resource.

The SDT may make implicit structure explicit without inventing knowledge absent from the resource’s information domain.

4.17 The SDT Is Not a Shadow Page

The machine-facing representation should not become a second page containing unrelated claims, expanded marketing language, machine-targeted persuasion, or information that materially changes the subject of the human resource.

The SDT exists to represent knowledge associated with the resource—not to create a separate machine-only editorial surface.

Conceptually:

Human Representation
        ↘
         Underlying Knowledge
        ↗
SDT Representation

Both representations should remain grounded in the same information environment.

The SDT may be more explicit, more normalized, more relational, and more structurally precise.

It should not become semantically deceptive.

4.18 Machine Fact Objects

One useful way to understand factual knowledge inside an SDT is as a Machine Fact Object.

A Machine Fact Object is not a separate WebMEM Fragment Class.

It is the conceptual form of a machine-interpretable factual assertion whose meaning remains recoverable outside the human presentation context.

For example:

Subject:
segment:H5521-290-001

Predicate:
monthly_premium

Value:
18.50

Datatype:
currency

Unit:
USD

Plan Year:
2026

Provenance:
CMS PBP 2026

Derived:
false

The important object is not merely:

18.50

or even:

monthly_premium = 18.50 USD

It is the complete assertion context required to understand what the value means.

The applicable Fragment Class determines the larger semantic role in which that assertion participates.

For example:

DataFragment
└── Source-Observed Machine Fact Object

versus:

DerivedStatsFragment
└── Publisher-Derived Machine Fact Object

The factual assertion does not replace the Fragment Class.

It exists within it.

4.19 SDT Composition Is Selective

An SDT does not need to reproduce every fact available to the publisher.

Nor should it become an indiscriminate dump of backend data.

The publisher selects knowledge appropriate to the resource and organizes it according to semantic responsibility.

For example, a county Medicare resource may have backend access to:

hundreds of plan benefit fields
pharmacy networks
provider networks
formularies
historical enrollment
carrier metadata
county demographics
plan performance
pricing
service-area records

That does not mean every field belongs in the county SDT.

The appropriate question is:

What knowledge is necessary to represent the information domain of this resource coherently and preserve the semantics machines would otherwise need to reconstruct?

This creates a boundary between knowledge representation and data dumping.

4.20 SDT Boundaries

The SDT boundary should generally follow the semantic scope of the canonical web resource.

For example:

County Medicare Options Resource
        ↓
County Medicare Options SDT

or:

Contract Resource
        ↓
Contract SDT

or:

Plan Resource
        ↓
Plan SDT

The SDT may reference knowledge represented elsewhere without reproducing the entirety of those external resources.

For example:

County SDT
→ identifies available Plan
→ canonicalResource
→ Plan Resource

The Plan Resource may then publish its own SDT containing deeper plan-specific knowledge.

This allows machine-facing knowledge to remain modular across the web rather than requiring one resource to reproduce an entire domain graph.

4.21 SDTs and Resolvers

Resolver resources provide a particularly clear example of SDT composition.

A Resolver begins from a known identifier, entity, collection, or context and exposes the resolution structure surrounding it.

For example:

Contract Resolver
        ↓
SDT
│
├── IdentityFragment
│   └── Contract Identity
│
├── IndexFragment
│   └── Related Plans
│
├── DataFragment
│   └── Current Performance
│
├── DerivedStatsFragment
│   └── Historical Analysis
│
└── Relationships
    ├── operatedBy → Carrier
    ├── hasPlan → Plans
    └── canonicalResource → Related Resources

The Resolver is the publishing architecture.

The SDT is its machine-facing knowledge representation.

The fragments are the semantic knowledge objects inside that representation.

The relationships expose how those objects connect.

Resolution describes how applicable knowledge may be reached.

These concepts work together without collapsing into one another.

4.22 SDTs and Canonical Resources

An SDT may identify resources through which machine resolution can continue.

For example:

plan:H5521-290-0
→ canonicalResource
→ https://example.org/plans/H5521-290-0/

The entity and its canonical resource remain distinct:

Plan Entity
≠
Plan Web Resource

This distinction allows an SDT to expose enough information to establish identity and relationships while directing deeper resolution toward another resource.

The result is a distributed knowledge architecture built from canonical resources rather than a requirement that every page contain everything known about every related entity.

4.23 The SDT Does Not Prescribe Machine Behavior

Publishing an SDT does not require a consuming system to use it.

A search engine, answer engine, language model, crawler, agent, or other consumer may:

parse the complete SDT;
inspect selected fragments;
extract individual assertions;
follow relationships;
evaluate provenance;
use canonical resources;
combine the SDT with other sources;
or ignore the representation entirely.

The SDT is a publisher-side representation.

It makes semantic structure available.

It does not prescribe how external systems must process that structure.

4.24 From Fragment Recognition to Semantic Recoverability

The original Part 4 described Semantic Data Templates as a mechanism for AI fragment recognition.

The current architecture defines a broader objective.

The question is no longer simply:

Can a machine recognize this value as a discrete fragment?

It is:

Can the machine recover enough of the publisher’s known semantics to interpret the knowledge correctly outside the human presentation context?

That may require recovering:

fragment identity;
Fragment Class;
subject identity;
predicate;
value;
datatype;
unit;
provenance;
derivation status;
relationships;
applicability;
and resolution state.

Fragment recognition was an early expression of the problem.

Semantic recoverability is the more complete publishing objective.

4.25 The New Semantic Anchor

The original Semantic Anchor Layer attempted to anchor machine knowledge to individual visible HTML elements.

The current model moves the anchor deeper.

The anchor is no longer primarily:

Visible DOM Element
→ Machine Metadata

It is:

Publisher Knowledge
        ↓
Stable Identity
        ↓
Human Representation
+
Machine Representation

Identity, provenance, and shared underlying data provide the semantic anchor between the two publishing layers.

This is a stronger relationship because it does not depend on a particular page layout.

A table can become cards.

A paragraph can become a comparison interface.

A desktop layout can become a mobile layout.

The human representation can change.

The machine representation can change serialization.

The underlying entity and assertion semantics remain stable.

The durable anchor is the knowledge—not the DOM element that happens to display it.

4.26 Semantic Data Templates as Publishing Infrastructure

The Semantic Data Template began as a technique for attaching machine-readable semantics to page fragments.

It has evolved into something more fundamental.

The SDT is the machine-facing publication layer through which the publisher can preserve the structure of its knowledge at the web-resource boundary.

It allows the publisher to move from:

Human Document
→ machine must reconstruct meaning

toward:

Underlying Knowledge
        ↓
   ┌────┴────┐
   ↓         ↓
Human      Machine
Document   Knowledge
           Representation

The objective is not to duplicate the page.

It is not to condition machine memory.

It is not to attach metadata to every visible element.

It is to preserve what the publisher knows when knowledge crosses from internal systems into public web publication.

The document tells the story.

The SDT preserves the knowledge behind it.