Anatomy of a Semantic Data Template

Part of the WebMEM® Protocol
Location: /protocol/sdt/anatomy/
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 is composed of modular WebMEM fragments. Each fragment has a defined Fragment Class that establishes the semantic purpose of the knowledge it contains. Within those fragments are the assertions, structures, relationships, and references through which the publisher expresses the actual knowledge associated with the resource.

The basic hierarchy is:

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

This hierarchy separates three different questions:

SDT: What body of machine-facing knowledge is associated with this resource?
Fragment: What semantic role does this part of the knowledge perform?
Assertions and Structures: What does the publisher actually state, define, organize, relate, or prescribe?

Identity, context, provenance, relationships, and resolution semantics operate across these levels to preserve meaning.

The Web Resource

The web resource is the publication surface to which the SDT belongs.

It may be:

a page describing an entity;
a geographic plan directory;
a product or service resource;
a policy or regulatory resource;
a glossary;
a procedural guide;
a resolver;
or another web resource containing knowledge that can be represented structurally.

The human-facing document and the SDT are associated with the same resource, but they serve different consumers.

The human-facing representation may communicate through prose, tables, visual hierarchy, navigation, interactive elements, and other presentation structures.

The SDT communicates through explicit semantic objects and relationships.

The SDT should therefore represent the knowledge of the resource rather than attempt to reproduce its visual or editorial presentation.

The SDT

The SDT is the composition boundary for the machine-facing knowledge representation of the resource.

It provides the structure within which multiple WebMEM fragments can participate in one coherent representation.

An SDT may establish or preserve shared context such as:

the primary subject of the resource;
resource identity;
geographic scope;
temporal scope;
jurisdiction;
dataset scope;
publisher identity;
and relationships applicable across multiple fragments.

Not every SDT requires every form of context. The SDT should represent the context necessary to interpret the knowledge actually published by the resource.

The SDT does not determine the semantic role of every individual assertion. That responsibility belongs to the Fragment Classes contained within it.

Fragments

A WebMEM fragment is a modular knowledge object within an SDT.

Each fragment declares a Fragment Class.

The Fragment Class establishes the semantic contract governing the knowledge represented by that fragment.

For example:

Fragment Class	Semantic Role
`DataFragment`	Represents source-observed factual knowledge.
`DerivedStatsFragment`	Represents calculated, aggregated, or otherwise derived knowledge.
`IndexFragment`	Represents membership within a defined collection.
`DefinedTermFragment`	Represents the canonical meaning of an individual term.
`FAQFragment`	Represents a structured 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 glossary or semantic vocabulary.
`PersonaFragment`	Represents a contextual human model, archetype, or scenario.
`PolicyFragment`	Represents governing policies, rules, conditions, and exceptions.
`RecommendationFragment`	Represents a publisher-defined recommendation and its basis.
`IdentityFragment`	Represents the canonical structured identity of an entity.

The SDT does not flatten these different kinds of knowledge into one universal record structure.

Fragment Classes preserve semantic differences that matter.

Read the WebMEM Fragments specification →

Assertions

An assertion is a statement of knowledge made by the publisher within the semantic context of a fragment.

Assertions are especially important within fragment classes that represent factual or derived knowledge.

For example, a DataFragment describing a Medicare plan may contain assertions such as:

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

The Fragment Class establishes that these are source-observed factual assertions.

If the same type of values occur within a DerivedStatsFragment, the Fragment Class establishes instead that they are derived or calculated assertions.

The assertion does not need to independently reproduce every piece of context already established unambiguously by the containing fragment or SDT.

This allows WebMEM to preserve atomic factual meaning without turning every value into an isolated knowledge object.

Read Facts and Assertions →

Structures

Not all knowledge inside a fragment is appropriately described as a factual assertion.

Different Fragment Classes contain different kinds of semantic structures.

For example:

a ProcedureFragment contains ordered steps and conditional paths;
a PolicyFragment contains rules, conditions, exceptions, and applicability;
an EligibilityFragment contains qualification criteria and logic;
a DirectoryFragment contains directory entries and their attributes;
an IndexFragment contains collection membership;
a GlossaryFragment contains a semantic collection of defined terms;
an FAQFragment contains a question-and-answer relationship;
and an IdentityFragment contains identifiers, roles, affiliations, classifications, and other identity structures.

These structures should not be forced into a universal fact-object abstraction simply because they are machine-readable.

The Fragment Class determines what kind of semantic structure its contents represent.

Shared Context

Meaning within an SDT can be established at more than one level.

Some context applies to the entire SDT. Some applies to a fragment. Some applies only to an individual assertion or structure.

For example:

SDT
  geography: Mohave County, Arizona
  plan_year: 2026

  DataFragment
    entity: plan:H5521-290-0
    source: CMS PBP

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

In this example:

the SDT establishes geographic and temporal context;
the DataFragment establishes entity and source context;
and the individual assertions establish their predicates, values, and units.

The meaning of an assertion is therefore determined by the assertion itself together with the applicable context inherited from its containing structures.

Context Inheritance

WebMEM allows applicable context to be established at the highest level where that context remains accurate and unambiguous.

This avoids unnecessary repetition while preserving meaning.

For example, if twenty factual assertions describe the same entity, apply to the same plan year, and originate from the same source, those properties do not need to be repeated twenty times solely to make each assertion appear self-contained.

Instead:

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

  Assertion
  Assertion
  Assertion
  Assertion

Each assertion inherits the applicable fragment context.

Context inheritance must not be used when doing so would create ambiguity.

If one assertion has a different source, time period, geography, entity scope, derivation method, or other material context, that distinction must be represented at the appropriate level.

Shared context may be inherited. Material differences must remain explicit.

Identity

Identity determines what an assertion or structure describes.

An SDT may represent multiple related entities, and those entities may exist at different levels of scope.

For example:

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

A contract, plan, and segment may share identifiers or relationships, but they are not the same entity.

An assertion about one should not automatically be generalized to another.

An IdentityFragment may establish the canonical identity of an entity when explicit identity representation is required, while other fragments may reference that established entity identity.

Identity therefore provides one of the primary anchors through which knowledge remains attached to the correct subject.

Read the Identity specification →

Provenance

Provenance establishes where knowledge came from and how its evidentiary lineage should be understood.

Like other context, provenance may operate at different levels of an SDT.

For example:

SDT
  Fragment A
    source: Dataset A
    Assertion
    Assertion

  Fragment B
    source: Dataset B
    Assertion
    Assertion

  DerivedStatsFragment
    sources:
      - Dataset A
      - Dataset B
    derivation: publisher-defined calculation
    Assertion

The first two fragments contain source-observed assertions from different datasets.

The DerivedStatsFragment contains a publisher-derived assertion based on those source datasets.

Flattening all three into one undifferentiated provenance statement would destroy an important distinction in the knowledge model.

Provenance should therefore be attached or inherited at the level necessary to preserve the actual lineage of the knowledge.

Read the Provenance specification →

Relationships

Relationships connect the objects represented within an SDT.

They may connect:

one entity to another entity;
a fragment to its subject;
an assertion to a defined term;
a directory entry to a canonical entity;
a policy to an eligibility requirement;
a procedure to a policy;
a recommendation to its supporting knowledge;
an indexed member to an IdentityFragment;
or an entity to a canonical resource.

Relationships allow machines to move beyond isolated assertions and understand how publisher knowledge is connected.

A relationship should preserve the identity of the objects it connects and the nature of the connection between them.

Read the Relationships specification →

Temporal, Geographic, and Applicability Context

Many assertions are true only within a particular scope.

That scope may be:

temporal;
geographic;
jurisdictional;
population-specific;
product-specific;
program-specific;
conditional;
or otherwise limited.

For example:

$0 premium

may be accurate only for:

plan: H5521-290-0
segment: 001
geography: Mohave County, Arizona
plan_year: 2026

Removing the applicability context can transform an accurate assertion into an inaccurate generalization.

The SDT architecture therefore treats applicability as part of meaning rather than as incidental metadata.

Resolution Semantics

Some knowledge cannot be interpreted safely until another piece of information has been resolved.

For example, an identifier may refer to a parent entity whose applicable value depends on a geographic segment.

The correct knowledge path may therefore be:

Plan ID
→ Plan Identity
→ Geographic Context
→ Segment
→ Applicable Value

rather than:

Plan ID
→ Value

The SDT can preserve the identities, relationships, and contextual dependencies necessary to represent that distinction.

Resolution semantics do not require a consuming system to follow a prescribed reasoning process. They make the publisher’s known resolution structure explicit.

Read the WebMEM Resolution Model →

Composition Across Fragment Classes

The power of an SDT comes from composition.

A single resource may require several Fragment Classes to represent its knowledge correctly.

For example:

Semantic Data Template
│
├── IdentityFragment
│   └── County identity
│
├── MetaFragment
│   └── CMS source dataset metadata
│
├── IndexFragment
│   └── Plans available in the county
│
├── DataFragment
│   └── Source-observed market facts
│
├── DerivedStatsFragment
│   └── Calculated county statistics
│
├── GlossaryFragment
│   └── Applicable Medicare vocabulary
│
└── DefinedTermFragments
    └── Canonical definitions

No single fragment needs to represent everything the resource knows.

Each fragment performs its own semantic job. The SDT composes those objects into one coherent representation.

Read SDT Composition →

Fragment Granularity

A fragment should contain a coherent body of knowledge appropriate to its Fragment Class.

The protocol does not define fragment granularity simply by the number of fields or assertions a fragment contains.

A fragment may contain one assertion or many assertions when they share a coherent subject, semantic role, and applicable context.

For example, these values may appropriately belong to one DataFragment:

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

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

Creating four independent fragments would not necessarily make the knowledge more precise. It could instead duplicate shared context and weaken the relationship among facts describing the same entity from the same source.

Conversely, combining unrelated entities, sources, semantic roles, or applicability contexts into one fragment may make the fragment too broad to interpret reliably.

Fragment boundaries should preserve semantic coherence without creating unnecessary duplication or collapsing materially different knowledge into the same object.

Avoiding Meaningless Atomization

The smallest technically separable unit of data is not always the most useful unit of machine knowledge.

A value such as:

may be individually extractable, but its meaning depends on surrounding knowledge:

entity: plan:H5521-290-0
plan_year: 2026
field: maximum_out_of_pocket
value: 4900
unit: USD
source: CMS PBP

WebMEM does not require every component of that assertion to become a separate fragment or independently published knowledge object.

Doing so can force a consuming system to reconstruct the very context the publisher already possesses.

The SDT instead allows coherent context to be preserved at the SDT, fragment, assertion, or structural level where it naturally applies.

This creates a balance between:

atomic precision — individual assertions remain distinguishable;
semantic coherence — related assertions remain connected to the context that gives them meaning;
modularity — different kinds of knowledge remain independently identifiable through Fragment Classes;
and economy — shared context does not need to be redundantly repeated.

The goal is not maximum atomization.

The goal is the smallest useful unit of knowledge that preserves the meaning necessary for correct interpretation.

Conceptual Anatomy and Serialization

The anatomy described on this page is conceptual.

It defines how knowledge is organized within an SDT, not the syntax used to publish that knowledge.

The conceptual structure:

SDT
└── Fragment
    ├── Assertions
    ├── Structures
    ├── Context
    ├── Relationships
    └── Provenance

may be represented through the current HTML-in-HTML serialization without making the serialization itself part of the conceptual model.

For example:

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

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

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

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

    </section>

  </template>

</template>

The HTML elements and data-* attributes serialize the knowledge model.

They do not define the conceptual meaning of the SDT, Fragment Class, assertion, identity, relationship, or provenance object.

This separation allows the WebMEM knowledge model to remain stable even if additional serialization methods are defined in the future.

Read the HTML-in-HTML Serialization specification →

Dataset Declaration

The internal anatomy of an SDT is distinct from the page-level mechanism used to declare that the SDT exists.

Under the current WebMEM publishing model, Schema.org Dataset JSON-LD may provide a standards-based discovery and declaration layer for the SDT.

The relationship is:

Web Resource
│
├── Dataset JSON-LD
│   └── Declares and describes the machine-facing dataset
│
└── Semantic Data Template
    ├── Fragment
    ├── Fragment
    └── Fragment

The Dataset declaration describes the page-level dataset.

The SDT provides the semantic organization of the knowledge contained within that dataset.

The two may share a stable identity so that the Dataset declaration maps explicitly to the corresponding SDT.

Dataset JSON-LD declares the dataset. The SDT defines its machine knowledge structure.

Read Dataset Declaration and SDT Mapping →

Conformance

A conforming SDT anatomy must preserve the distinctions among the structural levels of the WebMEM knowledge model.

Specifically:

the SDT must remain identifiable as the page-level machine knowledge representation;
fragments must remain identifiable as modular knowledge objects within the SDT;
each fragment must identify its Fragment Class;
the Fragment Class must determine the semantic role of the assertions or structures represented within that fragment;
assertions must retain enough direct or inherited context to preserve their intended meaning;
structural knowledge must not be forced into a factual assertion model when its Fragment Class defines another semantic form;
shared context may be inherited when its applicability is unambiguous;
material differences in identity, source, derivation, time, geography, jurisdiction, or applicability must remain explicit;
relationships must preserve the identities and semantic roles of the objects they connect;
fragment boundaries must preserve semantic coherence;
and the conceptual anatomy must remain distinguishable from the serialization used to publish it.

Conformance does not require every SDT to contain the same Fragment Classes, the same number of fragments, or the same internal structures.

The appropriate anatomy is determined by the knowledge actually represented by the resource.

Relationship to WebMEM 1.x

WebMEM 1.x introduced many of the structural concepts that evolved into the current SDT architecture, including fragments, fields, shared headers, provenance, glossary alignment, fragment relationships, and inheritance.

Earlier specifications, however, closely coupled those concepts to YAML-in-HTML syntax, semantic digests, fragment scopes, retrieval mechanisms, and other implementation structures.

The current protocol separates the conceptual knowledge model from its serialization.

It also clarifies the hierarchy that emerged from that earlier work:

Web Resource
└── Semantic Data Template
    └── WebMEM Fragment
        └── Assertions and Structures

The SDT is the page-level representation.

The Fragment Class establishes the semantic role of a modular knowledge object.

The assertions and structures within that fragment communicate the actual knowledge.

Identity, provenance, relationships, applicability, and resolution semantics preserve the context necessary to interpret that knowledge correctly.

This model retains the useful modularity developed in WebMEM 1.x while avoiding the assumption that every individual value must become an independent semantic object.

The current SDT anatomy is organized around coherent meaning, not maximum fragmentation.

Anatomy of a Semantic Data Template

Overview

The Web Resource

The SDT

Fragments

Assertions

Structures

Shared Context

Context Inheritance

Identity

Provenance

Relationships

Temporal, Geographic, and Applicability Context

Resolution Semantics

Composition Across Fragment Classes

Fragment Granularity

Avoiding Meaningless Atomization

Conceptual Anatomy and Serialization

Dataset Declaration

Conformance

Relationship to WebMEM 1.x

Related SDT Documents

Related Protocol Documents