Semantic Data Template (SDT)

Part of the WebMEM® Protocol
Location: /protocol/sdt/
Status: Current Draft
Last Updated: 2026-08-24

Overview

A Semantic Data Template (SDT) is the page-level machine knowledge representation defined by the WebMEM Protocol.

An SDT organizes the structured knowledge associated with a web resource into a coherent collection of WebMEM fragments. Those fragments identify the semantic role of the knowledge being published and preserve the identity, facts, definitions, relationships, provenance, policies, procedures, context, and other structures necessary for machines to interpret that knowledge correctly.

The SDT is not itself a single fact, fragment, dataset, or serialization format. It is the semantic container for the machine-facing knowledge representation of the resource.

In its simplest form:

Web Resource → Semantic Data Template → WebMEM Fragments → Assertions and Structures

This hierarchy allows a publisher to expose machine-readable knowledge without reducing the resource to either one large undifferentiated data object or hundreds of disconnected atomic values.

Why the SDT Exists

Traditional web publishing primarily organizes information for human consumption. A page may contain headings, paragraphs, tables, navigation, citations, and visual presentation that allow a human reader to infer what the page is about and how its information fits together.

Machines face a different problem.

A machine may encounter an individual value, identifier, statement, table row, definition, or relationship without reliably reconstructing all of the context that gives that information meaning.

Consider the value:

15.26

By itself, the value communicates almost nothing.

Additional structure may establish that it represents:

a monetary value;
a Medicare Advantage premium;
an average rather than an individual plan premium;
a particular county;
a particular plan year;
a defined population of plans;
a value derived using a stated method;
and an assertion grounded in identified source data.

The numerical value has not changed.

The meaning surrounding the value has.

The SDT exists to preserve that meaning as structured publisher knowledge.

The Semantic Boundary of an SDT

An SDT represents the machine-facing knowledge associated with a defined web resource.

Its boundary is semantic.

The SDT should contain the structured knowledge necessary to represent what the resource knows and intends to communicate within its declared scope.

That may include:

the identity of the primary subject;
source-observed factual assertions;
derived statistics and calculations;
collections and indexes;
definitions and glossary structures;
directories;
eligibility requirements;
procedures;
policies;
explanations;
personas or contextual scenarios;
recommendations;
relationships among entities and knowledge objects;
provenance;
temporal and geographic context;
and information necessary for machine resolution.

An SDT does not need to reproduce every word or presentation element visible on the human-facing page.

Its purpose is to represent the knowledge structure of the resource, not to create a machine-oriented copy of the rendered document.

SDTs and WebMEM Fragments

An SDT is composed of one or more WebMEM fragments.

A fragment is a modular knowledge object with a defined semantic purpose.

The Fragment Class tells a consuming system what kind of knowledge the fragment represents.

For example:

DataFragment represents source-observed factual knowledge;
DerivedStatsFragment represents calculated or aggregated knowledge;
IndexFragment represents membership in a defined collection;
DefinedTermFragment represents the canonical meaning of a term;
FAQFragment represents a question-and-answer knowledge object;
MetaFragment represents metadata about an information resource or dataset;
ExplainerFragment represents structured explanatory knowledge;
DirectoryFragment represents a structured directory of identifiable entries;
EligibilityFragment represents qualification criteria and eligibility logic;
ProcedureFragment represents ordered procedural knowledge;
GlossaryFragment represents an organized semantic vocabulary;
PersonaFragment represents a contextual human model or scenario;
PolicyFragment represents governing policies, rules, conditions, and exceptions;
RecommendationFragment represents a publisher-defined recommendation and its basis;
and IdentityFragment represents the canonical structured identity of an entity.

These classes are not competing representations of the same knowledge. They define different semantic roles that may participate together within one SDT.

Read the WebMEM Fragments specification →

Assertions and Structures Within Fragments

Fragments contain the actual assertions and structures being communicated by the publisher.

The nature of those contents is determined by the Fragment Class.

A DataFragment, for example, may contain factual assertions such as:

monthly_premium = 0 USD
plan_type = PPO
primary_care_copay = 0 USD
maximum_out_of_pocket = 4900 USD

A DerivedStatsFragment may contain:

plan_count = 42
average_premium = 27.42 USD
zero_premium_percentage = 61.9 percent

A ProcedureFragment, however, primarily contains ordered steps rather than factual assertions.

A PolicyFragment contains rules, conditions, and exceptions.

A DirectoryFragment contains identifiable directory entries and their applicable attributes.

An IdentityFragment establishes entity identity, identifiers, roles, affiliations, and structural relationships.

The WebMEM Protocol therefore does not require every internal element of every fragment to conform to a universal fact-object model.

The Fragment Class establishes the semantic contract for the assertions and structures contained within that fragment.

Read Facts and Assertions →

Facts Are More Than Values

A machine-readable value is not necessarily a machine-usable factual assertion.

For example:

becomes more meaningful when represented as:

maximum_out_of_pocket = 4900 USD

But correct interpretation may still require additional context:

subject: plan:H5521-290-0
plan_year: 2026
maximum_out_of_pocket: 4900
unit: USD
source: CMS Plan Benefit Package data
derived: false

Within WebMEM, some of that information may be represented directly with the assertion while other information may be established by the containing fragment, related identity objects, provenance, or the broader SDT.

The requirement is not that every value repeat every piece of context.

The requirement is that the knowledge representation preserve enough context for the assertion to retain its intended meaning.

Context and Inheritance

An SDT may establish context that applies across multiple fragments or assertions.

A fragment may likewise establish context shared by multiple internal elements.

For example, a DataFragment may establish:

entity: plan:H5521-290-0
plan_year: 2026
source: CMS PBP

and then contain multiple factual assertions:

monthly_premium = 0 USD
primary_care_copay = 0 USD
specialist_copay = 35 USD
maximum_out_of_pocket = 4900 USD

The shared entity, time, and source context does not need to be redundantly restated for every assertion when the applicable scope is unambiguous.

This is an important design principle of the SDT.

Context should be explicit, but explicit context does not require needless duplication.

Avoiding Meaningless Atomization

WebMEM does not require every individual value to become an independent fragment.

Excessive atomization can destroy useful context by separating closely related assertions that derive meaning from their shared entity, source, time period, methodology, or semantic purpose.

For example, representing every plan benefit as a completely independent fragment could require a consuming system to reconstruct repeatedly that all of those values:

describe the same plan;
apply to the same plan year;
come from the same source;
use the same vocabulary;
and participate in the same semantic context.

A DataFragment can preserve that shared context while allowing the individual factual assertions within it to remain distinguishable.

The appropriate granularity lies between two failure modes:

indiscriminate aggregation, where unrelated knowledge is collapsed into one large object; and
meaningless atomization, where related knowledge is separated so aggressively that its context must be reconstructed.

Fragment Classes provide the semantic boundary between those extremes.

Composition

An SDT becomes useful as a knowledge representation because multiple Fragment Classes can participate in the same coherent resource model.

Consider a resource describing Medicare coverage options within a county.

Its SDT might contain:

an IdentityFragment identifying the geographic entity;
an IndexFragment identifying the plans available within that geography;
one or more DataFragment objects containing source-observed plan or market facts;
a DerivedStatsFragment containing calculated county-level statistics;
a MetaFragment describing relevant source datasets;
DefinedTerm or Glossary fragments establishing domain terminology;
and relationships connecting those knowledge objects to one another and to canonical resources.

The fragments remain modular, but together they form the machine knowledge representation of the resource.

The SDT is the composition boundary.

Read SDT Composition →

Anatomy of an SDT

The conceptual hierarchy of an SDT is:

Web Resource
└── Semantic Data Template
    ├── Fragment
    │   ├── Assertions
    │   └── Structures
    ├── Fragment
    │   ├── Assertions
    │   └── Structures
    └── Fragment
        ├── Assertions
        └── Structures

The SDT establishes the page-level knowledge representation.

Fragments establish semantic roles within that representation.

Assertions and structures communicate the actual knowledge represented by those fragments.

Identity, provenance, relationships, context, and resolution semantics connect these objects into a coherent machine-interpretable whole.

Read Anatomy of an SDT →

SDT and Identity

Machine-readable knowledge requires stable subjects.

An SDT should therefore make clear what entities its knowledge describes and preserve distinctions among entities that exist at different levels of scope.

For example:

Carrier
└── Contract
    └── Plan
        └── Segment

These objects may be related, but they are not interchangeable.

A fact asserted about a contract should not automatically be interpreted as a fact about every plan under that contract. A segment-specific value should not automatically be generalized to the parent plan.

Identity provides the anchor that allows assertions and relationships to remain attached to the correct subject.

Read the Identity specification →

SDT and Provenance

An SDT should preserve the evidentiary basis of the knowledge it publishes.

Provenance may apply to:

an entire information resource;
a dataset represented by a MetaFragment;
a particular fragment;
a particular assertion;
a derived calculation;
a policy or procedure;
or another knowledge object within the SDT.

Provenance should be represented at the level necessary to preserve meaningful distinctions among sources and derivations.

Shared provenance may be inherited when multiple assertions genuinely have the same source basis. More specific provenance should be used when different assertions originate from different sources or transformations.

Read the Provenance specification →

SDT and Relationships

Knowledge objects within an SDT do not exist in isolation.

Relationships may connect:

entities to parent or child entities;
fragments to the entities they describe;
facts to defined terms;
policies to procedures;
eligibility requirements to programs;
directory entries to canonical resources;
recommendations to supporting knowledge;
identifiers to canonical entities;
and resources to other resolvable information objects.

These relationships allow a machine to understand not only what the publisher asserts, but how those assertions and objects fit together.

Read the Relationships specification →

SDT and Machine Resolution

An SDT does more than expose structured facts.

It can also provide the identity, relationships, scope, and contextual knowledge necessary for machines to determine how an information need connects to the appropriate information object.

For example:

County
→ IndexFragment
→ Plan ID
→ IdentityFragment
→ Plan
→ DataFragment
→ Plan Benefit

or:

Contract ID
→ Identity
→ Contract
→ Related Plans
→ Canonical Resources

or:

Program
→ EligibilityFragment
→ Qualification Criteria
→ ProcedureFragment
→ Application Resource

The SDT does not require a consuming system to follow any particular resolution path. It publishes the structured knowledge from which valid paths can be discovered or defined.

Read the WebMEM Resolution Model →

SDT and Dataset JSON-LD

A Semantic Data Template may be declared at the page level using Schema.org Dataset structured data.

This provides a standards-based discovery layer that identifies the machine-facing knowledge representation as a dataset associated with the web resource.

The two structures serve different purposes:

Dataset JSON-LD identifies and describes the dataset at the page level.
The SDT contains the structured machine knowledge represented by that dataset.
WebMEM fragments organize that knowledge according to semantic purpose.

The relationship can be understood as:

Web Resource → Dataset JSON-LD → Semantic Data Template → WebMEM Fragments → Assertions and Structures

Dataset JSON-LD does not replace the SDT and does not define the internal semantics of WebMEM fragments. It provides a widely recognized vocabulary through which the publisher can declare that a structured dataset exists on the page and describe its identity, subject, creator, temporal scope, distribution, licensing, and other applicable dataset-level metadata.

Mapping the Dataset to the SDT

The Dataset declaration should identify the same machine knowledge representation published by the SDT.

A simplified mapping may include:

Dataset Property	WebMEM Relationship
`@id`	Provides a stable page-level identifier for the dataset representing the SDT.
`name`	Provides a human-readable name for the machine knowledge dataset.
`description`	Describes the scope and contents of the SDT.
`url`	Identifies the web resource on which the SDT is published.
`creator`	Identifies the publisher or organization responsible for the dataset.
`dateModified`	Identifies the applicable modification date of the published dataset when available.
`temporalCoverage`	Identifies the time period represented by the SDT when applicable.
`spatialCoverage`	Identifies the geographic scope represented by the SDT when applicable.
`distribution`	May identify the WebMEM representation or another published distribution of the dataset.

The Dataset declaration and the SDT should describe the same underlying body of machine-facing knowledge rather than two unrelated datasets merely published on the same page.

Example Dataset Declaration

The following simplified example declares a page-level WebMEM dataset using Schema.org Dataset JSON-LD:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "@id": "https://example.org/resource/#webmem",
  "name": "Example Resource WebMEM Dataset",
  "description": "Structured machine knowledge associated with the Example Resource.",
  "url": "https://example.org/resource/",
  "creator": {
    "@type": "Organization",
    "name": "Example Publisher"
  },
  "dateModified": "2026-08-24",
  "distribution": {
    "@type": "DataDownload",
    "encodingFormat": "text/html",
    "contentUrl": "https://example.org/resource/#webmem"
  }
}
</script>

The corresponding SDT may use the same stable dataset identity:

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

  ...

</template>

The shared identity creates an explicit mapping between the page-level Dataset declaration and the WebMEM knowledge representation.

Schema.org declares that the dataset exists. WebMEM defines the structured knowledge the dataset contains.

SDT Is Not Serialization

A Semantic Data Template is a conceptual knowledge structure, not a serialization format.

This distinction is fundamental.

The SDT defines what knowledge is being represented and how that knowledge is semantically organized.

Serialization defines how that representation is encoded for publication or exchange.

The current WebMEM serialization uses HTML-in-HTML to publish the machine knowledge layer within the same HTML resource as the human-facing document.

A future serialization could represent the same SDT differently without changing the semantic meaning of the SDT itself.

The knowledge model and the transport syntax are separate concerns.

Read the Serialization specification →

HTML-in-HTML Serialization

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

A simplified resource may conceptually resemble:

<main>

  <h1>Human-Facing Resource</h1>

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

  <template
    data-webmem-sdt
    data-sdt-id="example-resource">

    <template
      data-webmem-fragment
      data-fragment-class="IdentityFragment"
      data-fragment-id="identity-example">

      <section
        data-entity-type="ExampleEntity"
        data-entity-id="entity:example">

        <h3 data-role="entity-name">
          Example Entity
        </h3>

      </section>

    </template>

    <template
      data-webmem-fragment
      data-fragment-class="DataFragment"
      data-fragment-id="data-example">

      <section
        data-entity-type="ExampleEntity"
        data-entity-id="entity:example">

        <data
          data-field="example_value"
          value="15.26"
          data-type="number"
          data-unit="USD">
          $15.26
        </data>

      </section>

    </template>

  </template>

</main>

The human-facing document and the machine knowledge representation occupy the same web resource but serve different purposes.

The visible document communicates through prose, layout, navigation, tables, graphics, and other presentation structures.

The SDT communicates through explicit identity, Fragment Classes, assertions, relationships, provenance, scope, and other semantic structures.

HTML-in-HTML is the current serialization used to carry that SDT within the resource. It is not the SDT itself.

Read the HTML-in-HTML Serialization specification →

Human and Machine Publishing

WebMEM treats the modern web resource as capable of serving two audiences simultaneously.

The human-facing layer can continue to use the forms of communication people expect:

prose;
headings;
tables;
navigation;
visual hierarchy;
interactive tools;
and other presentation-oriented structures.

The SDT provides a complementary machine-facing representation of the knowledge underlying that resource.

The two layers should describe the same underlying subject matter without requiring them to use the same presentation structure.

This is the foundation of dual publishing in WebMEM:

one resource, one underlying body of knowledge, two representations optimized for different consumers.

What an SDT Is Not

An SDT is not:

a replacement for the human-facing page;
a hidden copy of the page’s prose;
a collection of keywords for retrieval manipulation;
a universal schema requiring every resource to contain the same fields;
a requirement that every individual value become an independent fragment;
a replacement for provenance or source documentation;
a replacement for canonical entity identity;
a resolver by itself;
or a particular serialization syntax.

An SDT is the structured semantic representation through which a publisher organizes the machine-facing knowledge associated with a resource.

Conformance

A conforming Semantic Data Template must:

represent the machine-facing knowledge associated with a defined web resource or equivalent publication resource;
have an identifiable SDT scope;
contain one or more WebMEM fragments;
identify the Fragment Class of each fragment;
preserve enough identity and context to determine what the represented knowledge describes;
preserve the semantic distinctions among different types of knowledge represented by its Fragment Classes;
preserve provenance at the level necessary to distinguish materially different sources or derivations;
preserve relationships necessary to interpret how entities, fragments, assertions, and resources connect;
preserve temporal, geographic, jurisdictional, or other applicability context when that context materially affects meaning;
avoid requiring consuming systems to reconstruct essential meaning from disconnected values;
and conform to the applicable WebMEM serialization requirements.

An SDT does not need to contain every Fragment Class. It should contain the fragments necessary to represent the knowledge actually published by the resource.

Relationship to WebMEM 1.x

The Semantic Data Template originated in WebMEM 1.x and remains a foundational concept in the current WebMEM Protocol.

Earlier specifications sometimes described the SDT as the fragment format itself and closely coupled the concept to YAML-in-HTML, fragment headers, semantic digests, glossary scopes, retrieval hints, trust scoring, export formats, and related implementation mechanisms.

The current protocol clarifies the abstraction.

An SDT is the page-level machine knowledge representation. A WebMEM fragment is a modular knowledge object within that representation. HTML-in-HTML is a serialization of that representation.

This distinction separates three concerns that were previously intertwined:

Knowledge representation: the SDT defines the coherent machine-facing representation associated with the resource;
Semantic organization: Fragment Classes define the different roles performed by knowledge within the SDT;
Serialization: HTML-in-HTML defines how that knowledge representation is encoded for publication.

The current protocol also preserves an important lesson from the development of WebMEM 1.x: individual values require context, but attaching every possible piece of meaning independently to every value produces unnecessary duplication and excessive atomization.

The SDT provides the larger semantic boundary. Fragment Classes provide coherent modular boundaries within it. Assertions and structures carry the actual knowledge.

The object defines what the knowledge is. The container defines how the knowledge travels.

SDT Specification Documents

Anatomy of an SDT — the internal hierarchy of SDTs, fragments, assertions, structures, and shared context.
Facts and Assertions — how values become meaningful assertions and how factual context is represented without meaningless atomization.
SDT Composition — how multiple Fragment Classes combine into one coherent page-level machine knowledge representation.

Overview

Why the SDT Exists

The Semantic Boundary of an SDT

SDTs and WebMEM Fragments

Assertions and Structures Within Fragments

Facts Are More Than Values

Context and Inheritance

Avoiding Meaningless Atomization

Composition

Anatomy of an SDT

SDT and Identity

SDT and Provenance

SDT and Relationships

SDT and Machine Resolution

SDT and Dataset JSON-LD

Mapping the Dataset to the SDT

Example Dataset Declaration

SDT Is Not Serialization

HTML-in-HTML Serialization

Human and Machine Publishing

What an SDT Is Not

Conformance

Relationship to WebMEM 1.x

SDT Specification Documents

Related Protocol Documents