SDT Composition

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

Overview

SDT composition defines how multiple WebMEM fragments participate together in a single Semantic Data Template (SDT) to form the page-level machine knowledge representation of a web resource.

An SDT is not limited to one kind of knowledge. A resource may simultaneously identify an entity, publish source-observed facts, expose derived statistics, define terminology, establish relationships, describe policies, represent eligibility requirements, provide procedures, or organize a directory.

WebMEM represents these different semantic roles through Fragment Classes.

Composition is the process by which those modular knowledge objects become one coherent representation.

In simplified form:

Web Resource
└── Semantic Data Template
    ├── IdentityFragment
    ├── MetaFragment
    ├── IndexFragment
    ├── DataFragment
    ├── DerivedStatsFragment
    ├── DefinedTermFragment
    └── Other applicable fragments

The fragments remain semantically distinct. The SDT establishes that they participate in the same body of publisher knowledge.

The SDT Is the Composition Boundary

The SDT is the page-level boundary within which WebMEM fragments are composed.

This means that fragments contained within an SDT are understood to participate in the machine knowledge representation associated with the same resource.

The SDT may establish shared context applicable to multiple fragments, including:

the primary subject of the resource;
geographic scope;
temporal scope;
jurisdiction;
publisher identity;
dataset identity;
resource identity;
or other context that genuinely applies across the composed knowledge.

Composition does not mean that every fragment inherits every property of every other fragment.

Each fragment retains its own semantic role, subject scope, provenance, applicability, and internal structure except where shared context is explicitly established.

Composition Is Not Aggregation

Composition should not be confused with simply placing structured objects next to one another.

An SDT is coherent when the fragments it contains participate in a meaningful representation of the resource.

For example:

County Resource
│
└── SDT
    ├── IdentityFragment
    │   └── identifies the county
    │
    ├── IndexFragment
    │   └── identifies plans available in the county
    │
    ├── DataFragment
    │   └── publishes source-observed county plan facts
    │
    ├── DerivedStatsFragment
    │   └── publishes calculated county statistics
    │
    └── MetaFragment
        └── describes the source datasets

These fragments perform different jobs, but they describe related knowledge within the same resource context.

By contrast, placing unrelated fragments about unrelated subjects into the same SDT does not create meaningful composition merely because they share a container.

Composition requires semantic coherence.

Fragment Classes Are Semantic Roles

Fragment Classes allow an SDT to contain heterogeneous knowledge without flattening that knowledge into one generic record structure.

For example:

Fragment	Role Within the Composition
`IdentityFragment`	Establishes what an entity is and how it is identified.
`MetaFragment`	Describes an information resource or source dataset.
`DataFragment`	Publishes source-observed factual assertions.
`DerivedStatsFragment`	Publishes calculated or aggregated assertions.
`IndexFragment`	Establishes membership within a defined collection.
`DirectoryFragment`	Publishes a structured directory of identifiable entries.
`DefinedTermFragment`	Establishes the canonical meaning of an individual term.
`GlossaryFragment`	Organizes defined terms into a semantic vocabulary.
`PolicyFragment`	Represents governing rules, conditions, and exceptions.
`EligibilityFragment`	Represents qualification criteria and eligibility logic.
`ProcedureFragment`	Represents ordered procedural knowledge.
`ExplainerFragment`	Provides structured explanatory knowledge.
`FAQFragment`	Represents question-and-answer knowledge.
`PersonaFragment`	Provides a contextual human model or scenario.
`RecommendationFragment`	Represents a publisher-defined recommendation and its basis.

Composition allows these semantic roles to work together without requiring one class to absorb the responsibilities of another.

Read the WebMEM Fragments specification →

Composition Around a Primary Subject

Many SDTs are organized around a primary subject.

For example, a plan resource might establish:

Primary subject:
plan:H5521-290-0

Multiple fragments may then describe different aspects of that subject:

SDT
│
├── IdentityFragment
│   └── canonical plan identity
│
├── DataFragment
│   └── source-observed plan benefits
│
├── DerivedStatsFragment
│   └── calculated plan statistics
│
├── ExplainerFragment
│   └── explanation of an applicable benefit
│
└── PolicyFragment
    └── policy affecting the plan or benefit

The shared subject creates coherence across the fragments.

Not every fragment must describe the primary subject directly. A MetaFragment may describe a source dataset, and a DefinedTermFragment may describe a term used by the plan data.

Those fragments participate in the SDT because they support the knowledge represented about the primary subject.

Composition Around a Context

Some SDTs are organized less around one primary entity than around a defined context.

A county-level Medicare resource is a useful example.

The SDT may represent:

Context:
  geography: Mohave County, Arizona
  plan_year: 2026
  domain: Medicare

Within that context, different fragments may describe different entities and knowledge structures:

SDT
│
├── IdentityFragment
│   └── Mohave County
│
├── IndexFragment
│   └── Medicare Advantage plans available in the county
│
├── DataFragment
│   └── source-observed market facts
│
├── DerivedStatsFragment
│   └── county-level calculated statistics
│
├── MetaFragment
│   └── CMS Landscape source
│
└── GlossaryFragment
    └── Medicare terminology used by the resource

The fragments do not all describe the same entity.

They participate in the same SDT because they contribute to the same defined resource context.

Multiple Subjects Within One SDT

An SDT may contain knowledge about multiple entities when those entities participate in the same coherent resource model.

For example:

County
├── Plan A
├── Plan B
├── Plan C
└── Plan D

The county and plans are different entities.

An IndexFragment may establish the plans as members of the county’s available-plan collection. IdentityFragments may establish the canonical identity of individual plans. DataFragments may describe plan-specific facts.

The existence of multiple subjects does not require multiple SDTs when the subjects belong to the same coherent page-level knowledge representation.

The important requirement is that the subject of each assertion or structure remain identifiable.

Composition Through Identity

Identity is one of the primary mechanisms through which fragments can be composed safely.

For example:

IndexFragment
  member: plan:H5521-290-0

IdentityFragment
  entity: plan:H5521-290-0

DataFragment
  entity: plan:H5521-290-0

RecommendationFragment
  subject: plan:H5521-290-0

The shared entity identifier establishes that these fragments refer to the same plan while preserving the distinct semantic role of each fragment.

Composition should not depend solely on repeated human-readable labels when stable entity identity is available.

For example:

Example Health Medicare Advantage

may not uniquely identify an entity if multiple plans, contracts, segments, or years use similar names.

Stable identity allows composition to remain explicit.

Read the Identity specification →

Composition Through Relationships

Fragments may also be composed through explicit relationships.

For example:

PolicyFragment
  governs
      ↓
EligibilityFragment
  determines eligibility for
      ↓
Directory Entry
  enrollment process
      ↓
ProcedureFragment

or:

DataFragment
  provides input to
      ↓
DerivedStatsFragment
  supports
      ↓
ExplainerFragment

or:

IndexFragment
  contains member
      ↓
IdentityFragment
  resolves to
      ↓
Canonical Resource

Relationships make the composition explicit when simple co-membership in the same SDT would not communicate enough about how the knowledge objects connect.

Read the Relationships specification →

Composition Through Shared Context

Fragments may share context established by the SDT when that context applies to all participating fragments.

For example:

SDT
  geography: Mohave County, Arizona
  plan_year: 2026

  IndexFragment
  DataFragment
  DerivedStatsFragment

If all three fragments genuinely apply to the same county and plan year, the SDT may establish that shared context once.

However, shared context should not be applied to a fragment when the fragment has a different scope.

For example:

SDT
  geography: Mohave County, Arizona
  plan_year: 2026

  DataFragment
    geography: Mohave County
    plan_year: 2026

  MetaFragment
    source: CMS Landscape
    publication_scope: United States

The MetaFragment describes a national source dataset even though the page uses that dataset to represent county-level knowledge.

The SDT’s geographic context should not incorrectly redefine the source dataset as county-scoped.

Composition permits shared context. It does not erase fragment-specific scope.

Composition Through Provenance

Different fragments within an SDT may share provenance, use different sources, or combine multiple sources.

For example:

SDT
│
├── DataFragment
│   └── CMS Landscape
│
├── DataFragment
│   └── CMS Monthly Enrollment
│
├── DataFragment
│   └── CMS PBP
│
└── DerivedStatsFragment
    └── derived from Landscape + Enrollment

The fragments compose into one SDT because they contribute to the same resource knowledge.

Their provenance should not be flattened into one generic source declaration.

The DerivedStatsFragment should preserve which source knowledge was used in its derivation, while the individual DataFragments preserve their own source lineage.

Composition therefore combines knowledge without collapsing evidentiary distinctions.

Read the Provenance specification →

Composition of Source and Derived Knowledge

Source-observed and derived knowledge frequently coexist within the same SDT.

For example:

DataFragment
  plan_count_source_records = ...

DerivedStatsFragment
  average_premium = 27.42 USD
  zero_premium_percentage = 61.9 percent

The presence of derived knowledge does not change the semantic status of the source-observed assertions.

Likewise, the presence of source data does not make a calculated value source-observed.

The Fragment Classes preserve that distinction within the composed representation.

This allows a machine to understand both:

what the publisher obtained from an external source; and
what the publisher calculated or concluded from that source knowledge.

Composition of Definitions and Facts

Definitions may participate in the same SDT as the facts that use them.

For example:

DataFragment
  predicate: maximum_out_of_pocket
      ↓
DefinedTermFragment
  term: Maximum Out-of-Pocket
  definition: ...

GlossaryFragment
  contains:
    Maximum Out-of-Pocket

The DataFragment publishes the factual assertion.

The DefinedTermFragment establishes canonical meaning.

The GlossaryFragment establishes the semantic vocabulary in which the term participates.

Composition allows those roles to remain separate while making their relationship explicit.

Composition of Policies, Eligibility, and Procedures

Policy, eligibility, and procedural knowledge often form a natural composition.

For example:

PolicyFragment
  establishes governing rule
      ↓
EligibilityFragment
  expresses qualification criteria
      ↓
ProcedureFragment
  describes required process

These are not three representations of the same knowledge.

The PolicyFragment answers:

What rule applies?

The EligibilityFragment answers:

Under what conditions is the person or entity eligible?

The ProcedureFragment answers:

What must be done, and in what order?

Composition preserves these distinctions while allowing machines to traverse the relationships among them.

Composition of Directories and Indexes

IndexFragment and DirectoryFragment may coexist within the same SDT when the resource benefits from both collection membership and richer entry representation.

For example:

IndexFragment
  members:
    plan:H5521-290-0
    plan:H2406-129-0
    plan:H3931-129-0

DirectoryFragment
  entries:
    plan:H5521-290-0
      name
      plan_type
      premium
      canonical_resource

    plan:H2406-129-0
      name
      plan_type
      premium
      canonical_resource

The IndexFragment establishes which entities belong to the collection.

The DirectoryFragment publishes richer information about those entries.

Composition allows both representations to participate without requiring the index to become a directory or the directory to replace the index.

Composition and Recommendations

A RecommendationFragment may depend on knowledge represented elsewhere within the same SDT.

For example:

PersonaFragment
      ↓
EligibilityFragment
      ↓
DirectoryFragment
      ↓
RecommendationFragment
      ↓
ProcedureFragment

or:

DataFragment
      ↓
DerivedStatsFragment
      ↓
ExplainerFragment
      ↓
RecommendationFragment

The RecommendationFragment should preserve its own basis and applicability rather than relying on mere proximity to the supporting fragments.

Composition makes the supporting knowledge available. Explicit relationships establish why that knowledge supports the recommendation.

Composition and Resolution

Composition becomes especially important when a machine must traverse multiple kinds of knowledge before reaching an applicable answer or resource.

For example:

County
→ IndexFragment
→ Plan ID
→ IdentityFragment
→ Plan
→ Geographic Segment
→ DataFragment
→ Applicable Benefit

or:

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

The fragments participating in these paths perform different semantic jobs. Composition makes those knowledge objects available within the same coherent representation while identity and relationships preserve the paths among them.

The SDT does not require a consuming system to follow any particular path.

It provides the structured knowledge from which valid resolution paths can be represented, discovered, or traversed.

Read the WebMEM Resolution Model →

Composition Does Not Imply Inheritance

Membership in the same SDT does not mean that every property of one fragment applies to every other fragment.

For example:

SDT
  geography: Mohave County, Arizona
  plan_year: 2026

  IndexFragment
    subject: county:04015
    members:
      plan:H5521-290-0
      plan:H2406-129-0

  DataFragment
    subject: plan:H5521-290-0
    monthly_premium = 0 USD

  DataFragment
    subject: plan:H2406-129-0
    monthly_premium = 24.50 USD

The two plans participate in the same county-level SDT.

The premium asserted for one plan does not apply to the other plan merely because both fragments participate in the same composition.

Likewise:

an assertion about one entity does not automatically apply to related entities;
the provenance of one fragment does not automatically become the provenance of another;
a policy represented in one fragment does not automatically govern every object in the SDT;
a recommendation does not automatically apply to every persona or directory entry;
and geographic or temporal scope should not be inherited where a more specific scope applies.

Composition establishes participation. It does not establish semantic equivalence or universal inheritance.

Composition Does Not Imply Agreement

An SDT may contain knowledge objects that represent different perspectives, sources, time periods, classifications, or states without asserting that those objects are equivalent.

For example, an SDT may preserve:

a current value and a historical value;
an authoritative policy and an explanatory interpretation of that policy;
a source-observed value and a publisher-derived statistic;
a canonical term and an alternate term;
a primary recommendation and a fallback resource;
or current and retired identity relationships.

The relationships among those objects should preserve the distinctions necessary to interpret them correctly.

Composition provides the shared knowledge environment. It does not erase disagreement, chronology, authority, derivation, or semantic difference.

Composition and Fragment Granularity

Composition depends on choosing fragment boundaries that preserve coherent meaning.

A fragment should be broad enough to preserve useful shared context but narrow enough to maintain a clear semantic role.

For example:

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

is a coherent fragment because the assertions:

describe the same entity;
perform the same semantic role;
share the same temporal context;
and share applicable provenance.

By contrast, placing an unrelated policy, glossary definition, directory, and calculated statistic inside the same DataFragment would collapse distinct semantic roles into one object.

Those knowledge structures should instead be represented by their appropriate Fragment Classes and composed at the SDT level.

Fragments organize coherent knowledge. SDTs compose coherent fragments.

Composition and Reuse

The same identifiable entity, source, term, or other knowledge object may participate in more than one relationship within an SDT.

For example, one IdentityFragment may establish a plan identity that is referenced by:

an IndexFragment;
a DirectoryFragment;
a DataFragment;
an ExplainerFragment;
and a RecommendationFragment.

The identity does not need to be independently redefined by each fragment.

Similarly, a MetaFragment describing a source dataset may support multiple DataFragments and DerivedStatsFragments when those fragments genuinely depend on the same source.

A DefinedTermFragment may establish a canonical definition referenced by multiple factual, policy, procedural, or explanatory structures.

Composition therefore encourages reuse of stable identities and knowledge relationships rather than unnecessary duplication.

Composition Across Multiple Sources

A single SDT may legitimately represent knowledge assembled from multiple sources.

For example:

Medicare County SDT
│
├── MetaFragment
│   └── CMS Landscape
│
├── MetaFragment
│   └── CMS Monthly Enrollment
│
├── MetaFragment
│   └── CMS Plan Benefit Package
│
├── DataFragment
│   └── plan availability from Landscape
│
├── DataFragment
│   └── enrollment from Monthly Enrollment
│
├── DataFragment
│   └── benefits from PBP
│
└── DerivedStatsFragment
    └── publisher calculations using applicable source data

The SDT provides one coherent resource representation without pretending that all of the underlying knowledge came from one dataset.

Source boundaries should remain visible through provenance.

This is particularly important when datasets have different publication schedules, temporal scopes, methodologies, or authorities.

Composition Across Time

An SDT may contain historical and current knowledge when the resource intentionally represents change over time.

For example:

IdentityFragment
  entity: contract:H5521

DataFragment
  contract_year: 2025
  star_rating = 4.0

DataFragment
  contract_year: 2026
  star_rating = 4.5

Both assertions may participate in the same SDT if the resource represents contract history.

The temporal distinction must remain explicit so that the values are not treated as simultaneous assertions about the same period.

Composition across time should preserve chronology rather than flattening historical and current states together.

Composition and Page Scope

The appropriate composition of an SDT is determined by the semantic scope of the resource.

A plan page, county directory, contract resolver, glossary page, policy resource, and procedural guide may each require very different compositions.

For example:

Plan Resource
└── SDT
    ├── IdentityFragment
    ├── DataFragment
    ├── MetaFragment
    └── DefinedTermFragment

while:

Contract Resolver
└── SDT
    ├── IdentityFragment
    ├── IndexFragment
    ├── DirectoryFragment
    ├── DataFragment
    └── MetaFragment

and:

Eligibility Resource
└── SDT
    ├── PolicyFragment
    ├── EligibilityFragment
    ├── ProcedureFragment
    ├── DefinedTermFragment
    └── ExplainerFragment

There is no universal fragment recipe for every SDT.

The composition should reflect the actual knowledge and purpose of the resource.

Composition and the Human-Facing Resource

The SDT should remain semantically aligned with the resource to which it belongs.

This does not require the machine-facing representation to reproduce the visible document line by line.

A human-facing resource may communicate through:

narrative prose;
tables;
charts;
navigation;
interactive controls;
citations;
and other presentation structures.

The SDT may represent the underlying knowledge through a different composition optimized for machine interpretation.

But the two representations should not make materially conflicting assertions about the same subject and scope.

Composition reorganizes knowledge for machines. It does not create a separate factual reality from the human-facing resource.

Composition and Serialization

SDT composition is a property of the WebMEM knowledge model, not of a particular serialization syntax.

Conceptually:

SDT
├── Fragment A
├── Fragment B
├── Fragment C
└── Fragment D

Under the current HTML-in-HTML serialization, that composition may be represented as:

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

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

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

  <template
    data-webmem-fragment
    data-fragment-class="DerivedStatsFragment"
    data-fragment-id="derived-example">
    ...
  </template>

</template>

The nesting expresses the composition in the current serialization.

The semantic relationship among the SDT and its fragments exists independently of that syntax.

Read the HTML-in-HTML Serialization specification →

Composition and Dataset Declaration

The complete SDT composition may be declared as a page-level dataset using Schema.org Dataset JSON-LD.

The relationship is:

Web Resource
│
├── Dataset JSON-LD
│   └── declares the page-level machine dataset
│
└── SDT
    ├── Fragment
    ├── Fragment
    ├── Fragment
    └── Fragment

The Dataset declaration identifies and describes the composed machine-facing dataset.

The SDT defines the semantic composition of that dataset.

The individual Fragment Classes define the roles performed by the knowledge objects within the composition.

The Dataset declaration should not attempt to flatten the internal fragment composition into Schema.org properties when WebMEM already represents those distinctions explicitly.

Read Dataset Declaration and SDT Mapping →

Conformance

A conforming SDT composition must:

contain one or more identifiable WebMEM fragments;
identify the Fragment Class of each fragment;
preserve the semantic role of each Fragment Class within the composition;
maintain identifiable subjects or contexts for fragments whose meaning depends on them;
preserve material differences in entity scope, provenance, derivation, time, geography, jurisdiction, population, or applicability;
use shared context only where that context genuinely applies to the participating fragments;
avoid treating SDT membership as evidence that every fragment describes the same subject or inherits the same properties;
preserve explicit relationships when co-membership alone is insufficient to communicate how knowledge objects connect;
avoid collapsing semantically different forms of knowledge into an inappropriate Fragment Class;
maintain semantic alignment with the resource to which the SDT belongs;
and remain distinguishable from the serialization used to encode the composition.

A conforming SDT does not need to contain every Fragment Class.

It should contain the fragments necessary to represent the actual machine-facing knowledge of the resource within its declared semantic scope.

Relationship to WebMEM 1.x

WebMEM 1.x developed many of the mechanisms that made fragment composition possible, including shared fragment headers, inheritance, related-fragment references, semantic digests, provenance blocks, glossary scopes, and multiple Fragment Classes.

Those mechanisms established an important principle: a useful machine knowledge representation often requires multiple modular objects that share context and relationships.

The current protocol preserves that principle while simplifying the architecture.

The SDT is now explicitly defined as the page-level composition boundary.

Fragment Classes define the semantic roles of the knowledge objects within that boundary.

Identity, provenance, relationships, and applicable context establish how those objects participate together.

The current model therefore does not require a separate semantic-digest abstraction to explain why multiple fragments belong together. Their participation in the same SDT, combined with explicit identity and relationships where necessary, establishes the composition.

Likewise, composition no longer depends on YAML-specific inheritance syntax or retrieval-oriented fragment relationships.

The current model composes knowledge by semantic role, identity, context, provenance, and explicit relationships rather than by serialization-specific machinery.

SDT Composition

Overview

The SDT Is the Composition Boundary

Composition Is Not Aggregation

Fragment Classes Are Semantic Roles

Composition Around a Primary Subject

Composition Around a Context

Multiple Subjects Within One SDT

Composition Through Identity

Composition Through Relationships

Composition Through Shared Context

Composition Through Provenance

Composition of Source and Derived Knowledge

Composition of Definitions and Facts

Composition of Policies, Eligibility, and Procedures

Composition of Directories and Indexes

Composition and Recommendations

Composition and Resolution

Composition Does Not Imply Inheritance

Composition Does Not Imply Agreement

Composition and Fragment Granularity

Composition and Reuse

Composition Across Multiple Sources

Composition Across Time

Composition and Page Scope

Composition and the Human-Facing Resource

Composition and Serialization

Composition and Dataset Declaration

Conformance

Relationship to WebMEM 1.x

Related SDT Documents

Related Protocol Documents