The SDC4 Versioning Advantage

Document Type: Strategic Analysis (Open Source)

Audience: Enterprise architects, IT leaders, standards implementers

Status: Draft

Version: 1.0

Date: 2025-11-03

Authors: Timothy W. Cook (Founder, Axius SDC, Inc.) w/Claude (Anthropic AI Assistant)

Organization: Semantic Data Charter (open source community)

License: Creative Commons Attribution 4.0 International (CC BY 4.0)

Executive Summary

Both FHIR and NIEM face a fundamental challenge: when semantics and structure are coupled, versioning requires migration. SDC4's separation of concerns enables something revolutionary: data immortality—old data lives forever in its original form while new data uses evolved schemas, coexisting side-by-side without forced migration.

Key Insight: Because SDC4's foundation is stable structural types (Xd*Types), not semantic definitions, component versioning is semantic evolution, not structural breaking changes.

The Versioning Problem in FHIR
The Versioning Problem in NIEM
Why Coupling Semantics and Structure Forces Migration
SDC4's Revolutionary Approach
Component Versioning with CUID2
XPath Continuity and Query Stability
SDC4 ↔ SDC5 Coexistence
Economic Impact of Data Immortality
Real-World Scenarios

The Versioning Problem in FHIR

FHIR R4 → R5 Migration Reality

What Changes:

// FHIR R4
{
  "resourceType": "Patient",
  "identifier": [{
    "system": "http://example.org/mrn",
    "value": "12345"
  }],
  "name": [{
    "family": "Doe",
    "given": ["John"]
  }]
}

// FHIR R5 - New structure for name
{
  "resourceType": "Patient",
  "identifier": [{
    "system": "http://example.org/mrn",
    "value": "12345"
  }],
  "name": [{
    "family": "Doe",
    "given": [{"value": "John"}]  // Now an object, not string!
  }]
}

Impact:

Applications parsing R4 break on R5 data
Database schemas must be migrated
APIs must support both versions (dual implementation)
Queries need version-specific logic
Historical data requires transformation

FHIR Version Migration Costs

Typical Healthcare System (500-bed hospital):

Planning: 3-6 months, $200K-500K (vendor coordination, impact analysis)
Development: 6-12 months, $1M-3M (code changes, testing)
Data Migration: 2-4 months, $500K-1M (ETL jobs, validation)
Dual-Running: 6-12 months, $500K-1M (maintain both versions)
Training: $100K-300K (staff retraining)
Total: $2.3M-5.8M per system
Timeline: 18-36 months

National Scale (5,000 hospitals × $3.5M average):

Conservative Estimate: $17.5 billion
Hidden Costs: Delayed interoperability, system incompatibilities, data quality issues

Why FHIR Can't Avoid This

Problem: FHIR element names encode semantic meaning:

{
  "birthDate": "1985-05-15"  // Semantic meaning in property name
}

Consequence: If HL7 decides birthDate should have additional metadata (precision, source, confidence), they must:

Change the structure (breaking change)
Version the entire specification (R4 → R5)
Force everyone to migrate

Alternative Attempted: Extensions

{
  "birthDate": "1985-05-15",
  "extension": [{
    "url": "http://hl7.org/fhir/StructureDefinition/data-precision",
    "valueCode": "exact"
  }]
}

Problem with Extensions: Bloated, inconsistent, query complexity, poor discoverability

The Versioning Problem in NIEM

NIEM 4.0 → 5.0 Migration Reality

Namespace URI Changes:

<!-- NIEM 4.0 -->
<nc:Person xmlns:nc="http://release.niem.gov/niem/niem-core/4.0/">
  <nc:PersonBirthDate>
    <nc:Date>1985-05-15</nc:Date>
  </nc:PersonBirthDate>
</nc:Person>

<!-- NIEM 5.0 -->
<nc:Person xmlns:nc="http://release.niem.gov/niem/niem-core/5.0/">
  <nc:PersonBirthDate>
    <nc:Date>1985-05-15</nc:Date>
  </nc:PersonBirthDate>
</nc:Person>

Looks Similar, But:

Namespace URI is different → parsers reject 4.0 data in 5.0 context
Schema validation fails across versions
IEPDs (Information Exchange Package Documents) must specify exact version
Systems must coordinate major releases

NIEM Breaking Changes Example

NIEM 4.0 → 5.0 actual changes:

Removed: nc:PolygonCoordinate
Added: nc:PolygonNodeLocation
Changed: nc:PersonContactInformation structure

Impact:

Applications using PolygonCoordinate break
Emergency management systems (using polygon boundaries) require rewrites
Data stored with old element must be transformed
No backward compatibility guarantee

NIEM Migration Costs

Typical Federal Agency (medium size):

IEPD Updates: 20-50 IEPDs × $50K-100K = $1M-5M
System Updates: 10-30 systems × $200K-500K = $2M-15M
Testing: $500K-2M
Coordination: 13+ domains, NBAC review, 18-24 months
Total per agency: $3.5M-22M

Federal Government Scale (100+ agencies):

Conservative Estimate: $350M-2.2B per major release
3-Year Cycle: Agencies in perpetual migration state

Why NIEM Can't Avoid This

Problem: Element names encode domain consensus:

<nc:PersonSSNIdentification>
  <nc:IdentificationID>123-45-6789</nc:IdentificationID>
</nc:PersonSSNIdentification>

Consequence: If domains want to rename or restructure (e.g., PersonNationalIdentification for international), they must:

Negotiate harmonization across all 13+ domains
Update NIEM Core namespace
Change namespace URI (breaking change)
Force all agencies to migrate IEPDs

Why Coupling Semantics and Structure Forces Migration

The Fundamental Problem

When Structure = Semantics:

Change in Meaning → Change in Element Name → Change in Schema → Breaking Change

Example Timeline:

Year 1: Standard defines PatientBirthDate as simple date
Year 5: Realize need for date precision (exact vs. approximate)
Year 6: Propose structural change (add precision attribute)
Year 7: Negotiate change across stakeholders
Year 8: Release new version with breaking change
Year 8-10: Implementers migrate
Year 10: Some systems still on old version (technical debt)

The Migration Cascade

One Breaking Change Triggers:

Schema Updates: XSD, JSON Schema, database schemas
Code Changes: Parsers, validators, serializers
API Changes: REST endpoints, SOAP services
Data Migration: Transform millions/billions of records
Documentation: Update specs, guides, tutorials
Training: Retrain developers, users
Coordination: All systems must upgrade in sync (or dual-version support)

The Technical Debt Accumulation

Reality: Not everyone migrates on schedule

Healthcare: Some hospitals still on FHIR DSTU2 (2015) in 2025
Government: Some agencies still on NIEM 3.0 (2014) in 2025
Result: Fragmentation, incompatibility, integration hell

SDC4's Revolutionary Approach

Core Principle: Structural Stability + Semantic Evolution

SDC4 Foundation:

Xd*Types (Structural) → Stable, Rarely Change
Ontology URIs (Semantic) → Evolve Freely

Example - Version 1 Schema:

<xsd:complexType name="mc-gp7q9t2v01086">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-gp7q9t2v01086">
        <rdfs:label>Birth Date</rdfs:label>
        <rdfs:isDefinedBy rdf:resource="http://example.org/ontology/v1/birthDate"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:XdTemporalType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Birth Date"/>
        <xsd:element name="xdtemporal-value" type="xsd:date"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<!-- Instance -->
<sdc4:ms-gp7q9t2v01086>
  <label>Birth Date</label>
  <xdtemporal-value>1985-05-15</xdtemporal-value>
</sdc4:ms-gp7q9t2v01086>

Evolution Without Breaking - Version 2 Schema:

<!-- New complexType with different CUID2, enhanced semantics -->
<xsd:complexType name="mc-hr8s0u3w12097">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-hr8s0u3w12097">
        <rdfs:label>Birth Date</rdfs:label>
        <!-- New ontology version with precision -->
        <rdfs:isDefinedBy rdf:resource="http://example.org/ontology/v2/birthDate"/>
        <rdfs:isDefinedBy rdf:resource="http://example.org/ontology/v2/datePrecision#exact"/>
        <!-- Link to previous version for provenance -->
        <sdc4-meta:replacesVersion rdf:resource="sdc4:mc-gp7q9t2v01086"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:XdTemporalType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Birth Date"/>
        <xsd:element name="xdtemporal-value" type="xsd:date"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<!-- Instance uses new element name -->
<sdc4:ms-hr8s0u3w12097>
  <label>Birth Date</label>
  <xdtemporal-value>1985-05-15</xdtemporal-value>
</sdc4:ms-hr8s0u3w12097>

No Breaking Change: Structural pattern (XdTemporalType with xdtemporal-value) unchanged! Element names are structural identifiers (ms-[CUID2]), not semantic.

Component Versioning with CUID2

The CUID2 Strategy

CUID2: Collision-resistant Unique Identifier, sortable, secure

Versioning Pattern - Version 1 Schema:

<!-- ComplexType for PersonName v1 (mc-ck8j3n2p40001) -->
<xsd:complexType name="mc-ck8j3n2p40001">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-ck8j3n2p40001">
        <rdfs:label>Person Name v1</rdfs:label>
        <rdfs:isDefinedBy rdf:resource="http://example.org/ontology/v1/PersonName"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:ClusterType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Person Name v1"/>
        <xsd:element ref="sdc4:ms-is1t4v5x23108"/><!-- GivenName -->
        <xsd:element ref="sdc4:ms-jt2u5w6y34119"/><!-- FamilyName -->
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<!-- Instance -->
<sdc4:ms-ck8j3n2p40001>
  <label>Person Name v1</label>
  <sdc4:ms-is1t4v5x23108>
    <label>Given Name</label>
    <xdstring-value>John</xdstring-value>
  </sdc4:ms-is1t4v5x23108>
  <sdc4:ms-jt2u5w6y34119>
    <label>Family Name</label>
    <xdstring-value>Doe</xdstring-value>
  </sdc4:ms-jt2u5w6y34119>
</sdc4:ms-ck8j3n2p40001>

Evolution → Version 2 Schema (Add middle name support):

<!-- ComplexType for PersonName v2 (mc-cl9m5p8r60042) -->
<xsd:complexType name="mc-cl9m5p8r60042">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-cl9m5p8r60042">
        <rdfs:label>Person Name v2</rdfs:label>
        <rdfs:isDefinedBy rdf:resource="http://example.org/ontology/v2/PersonName"/>
        <!-- Provenance link to previous version -->
        <sdc4-meta:replacesVersion rdf:resource="sdc4:mc-ck8j3n2p40001"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:ClusterType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Person Name v2"/>
        <xsd:element ref="sdc4:ms-is1t4v5x23108"/><!-- GivenName (reused) -->
        <xsd:element ref="sdc4:ms-ku3v6x7z45120"/><!-- MiddleName (NEW) -->
        <xsd:element ref="sdc4:ms-jt2u5w6y34119"/><!-- FamilyName (reused) -->
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<!-- Instance -->
<sdc4:ms-cl9m5p8r60042>
  <label>Person Name v2</label>
  <sdc4:ms-is1t4v5x23108>
    <label>Given Name</label>
    <xdstring-value>John</xdstring-value>
  </sdc4:ms-is1t4v5x23108>
  <sdc4:ms-ku3v6x7z45120><!-- NEW component -->
    <label>Middle Name</label>
    <xdstring-value>Q</xdstring-value>
  </sdc4:ms-ku3v6x7z45120>
  <sdc4:ms-jt2u5w6y34119>
    <label>Family Name</label>
    <xdstring-value>Doe</xdstring-value>
  </sdc4:ms-jt2u5w6y34119>
</sdc4:ms-cl9m5p8r60042>

Key Properties:

New CUID2: cl9m5p8r60042 ≠ ck8j3n2p40001 (Cluster versions)
Component Reuse: GivenName and FamilyName components (ms-is1t4v5x23108, ms-jt2u5w6y34119) reused in both versions
New Component: MiddleName (ms-ku3v6x7z45120) only in v2
Semantic Link: replacesVersion in schema annotations points to old version
Coexistence: Both element names (ms-ck8j3n2p40001, ms-cl9m5p8r60042) can exist in same data model
No Migration Required: Old data uses v1, new data uses v2

XPath Continuity and Query Stability

The XPath Guarantee

SDC4 Structural Paths Are Stable:

Version 1 XPath (using structural element names):

//sdc4:ms-ck8j3n2p40001/sdc4:ms-is1t4v5x23108/xdstring-value

Version 2 XPath (using structural element names):

//sdc4:ms-cl9m5p8r60042/sdc4:ms-is1t4v5x23108/xdstring-value

Component-based XPath (finds given name component regardless of parent Cluster version):

//sdc4:ms-is1t4v5x23108/xdstring-value

Label-based XPath (human-readable, works across versions):

//*[label='Given Name']/xdstring-value

Key Pattern: Element names (ms-[CUID2]) are structural identifiers. The component for "Given Name" (ms-is1t4v5x23108) is reused across all PersonName Cluster versions. Only the parent Cluster element name changes (ms-ck8j3n2p40001 → ms-cl9m5p8r60042).

Query Evolution Example

Scenario: Hospital stores patient data over 10 years

2015: Uses PersonName v1 (ms-ck8j3n2p40001)

2020: Updates to PersonName v2 (ms-cl9m5p8r60042, adds middle name)

2025: Updates to PersonName v3 (ms-dm4n6q9s70053, adds prefix/suffix)

Query in 2025 (component-based):

//sdc4:ms-is1t4v5x23108/xdstring-value

Returns:

All given names from 2015 (within ms-ck8j3n2p40001 Clusters)
All given names from 2020 (within ms-cl9m5p8r60042 Clusters)
All given names from 2025 (within ms-dm4n6q9s70053 Clusters)

Alternative Query (label-based):

//*[label='Given Name']/xdstring-value

No Migration Required: Old data readable with new queries because:

Component identifiers are stable - ms-is1t4v5x23108 (GivenName) reused across all versions
Structural patterns are consistent - all use xdstring-value child element
XPath works across element name changes - queries can target the component or use label matching

SDC4 ↔ SDC5 Coexistence

Reference Model Evolution

When SDC5 Introduces New Xd*Types:

Imagine SDC5 adds:

XdVectorType (for multi-dimensional data)
XdStreamType (for continuous data streams)
XdGraphType (for network/graph data)

In SDC4 Data Model - Instance:

<sdc4:ms-lv4w7y0a56131 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Patient Data Cluster</label>
  <sdc4:ms-mw5x8z1b67142>
    <label>Name</label>
    <xdstring-value>Jane Smith</xdstring-value>
  </sdc4:ms-mw5x8z1b67142>
  <sdc4:ms-nx6y9a2c78153>
    <label>Birth Date</label>
    <xdtemporal-value>1990-03-15</xdtemporal-value>
  </sdc4:ms-nx6y9a2c78153>
</sdc4:ms-lv4w7y0a56131>

In SDC5 Data Model - Instance (using new XdVectorType):

<sdc5:ms-oy7z0b3d89164 xmlns:sdc5="https://semanticdatacharter.com/ns/sdc5/">
  <label>Patient Data Cluster v2</label>
  <sdc5:ms-mw5x8z1b67142><!-- Reused component from SDC4 -->
    <label>Name</label>
    <xdstring-value>John Doe</xdstring-value>
  </sdc5:ms-mw5x8z1b67142>
  <sdc5:ms-nx6y9a2c78153><!-- Reused component from SDC4 -->
    <label>Birth Date</label>
    <xdtemporal-value>2000-07-22</xdtemporal-value>
  </sdc5:ms-nx6y9a2c78153>
  <!-- NEW: SDC5-only type -->
  <sdc5:ms-pz8a1c4e90175>
    <label>Genomic Coordinates</label>
    <xdvector-value>[23.5, 45.2, 67.8]</xdvector-value>
  </sdc5:ms-pz8a1c4e90175>
</sdc5:ms-oy7z0b3d89164>

Coexistence in Same Database:

<sdc4:dm-cqavb8ypmfa5rsztomsrpd4z xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/"
                                  xmlns:sdc5="https://semanticdatacharter.com/ns/sdc5/">
  <dm-label>Multi-Version Patient Database</dm-label>

  <!-- SDC4 Cluster (legacy data from 2020) -->
  <sdc4:ms-lv4w7y0a56131>
    <label>Patient Data Cluster</label>
    <sdc4:ms-mw5x8z1b67142>
      <label>Name</label>
      <xdstring-value>Jane Smith</xdstring-value>
    </sdc4:ms-mw5x8z1b67142>
  </sdc4:ms-lv4w7y0a56131>

  <!-- SDC5 Cluster (new data from 2030) -->
  <sdc5:ms-oy7z0b3d89164>
    <label>Patient Data Cluster v2</label>
    <sdc5:ms-mw5x8z1b67142>
      <label>Name</label>
      <xdstring-value>John Doe</xdstring-value>
    </sdc5:ms-mw5x8z1b67142>
    <sdc5:ms-pz8a1c4e90175>
      <label>Genomic Coordinates</label>
      <xdvector-value>[23.5, 45.2, 67.8]</xdvector-value>
    </sdc5:ms-pz8a1c4e90175>
  </sdc5:ms-oy7z0b3d89164>
</sdc4:dm-cqavb8ypmfa5rsztomsrpd4z>

XPath Works Across Versions:

//sdc4:ms-mw5x8z1b67142/xdstring-value  /* Finds SDC4 Name */
//sdc5:ms-mw5x8z1b67142/xdstring-value  /* Finds SDC5 Name (same component reused) */
//*[local-name()='ms-mw5x8z1b67142']/xdstring-value  /* Finds ALL Names regardless of namespace */
//*[label='Name']/xdstring-value  /* Label-based query across all versions */

Key Benefit: No Forced Migration. SDC4 data lives alongside SDC5 data indefinitely. Components can be reused across major version boundaries (ms-mw5x8z1b67142 works in both SDC4 and SDC5 namespaces).

Economic Impact of Data Immortality

The Migration Tax

FHIR/NIEM Approach (Forced Migration):

Cost per Version = Development + Testing + Migration + Training + Downtime
Frequency = Every 3-5 years
Perpetual Cost = Organizations always planning/executing migrations

SDC4 Approach (Optional Evolution):

Cost per Version = None (optional evolution at component level)
Frequency = As needed, not coordinated
One-Time Cost = Only for systems choosing to use new features

Comparative Analysis

10-Year TCO for 1,000-Bed Hospital System:

Aspect	FHIR/NIEM	SDC4	Savings
Version Migrations	3 major releases	0 forced migrations	-
Migration Cost	3 × $3.5M = $10.5M	$0	$10.5M
Dual-Version Support	6 years × $500K = $3M	$0 (native coexistence)	$3M
Data Transformation	3 × $1M = $3M	$0	$3M
Training	3 × $300K = $900K	$0 (structure unchanged)	$900K
Integration Maintenance	$2M/year × 10 = $20M	$5M/year × 10 = $5M	$15M
Total 10-Year Cost	$37.4M	$5M	$32.4M (87% savings)

National Scale (5,000 hospitals):

Total Savings: $162 billion over 10 years

Hidden Benefits

Organizational:

No "migration freeze" periods (productivity maintained)
Continuous innovation (not waiting for next version)
Reduced coordination overhead (no need to synchronize upgrades)

Technical:

Simplified testing (no dual-version support)
Reduced technical debt (no legacy version support burden)
Historical data always accessible (no archive transformations)

Strategic:

Faster time-to-market for new features (semantic evolution, not structural)
Lower barrier to adoption (no migration fears)
Institutional knowledge preserved (old data always readable)

Real-World Scenarios

Scenario 1: Healthcare System Evolution

2020: Hospital implements SDC4-based EHR

<sdc4:ms-qw6a2d5g01186 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Patient Record</label>
  <sdc4:ms-rx7b3e6h12197>
    <label>MRN</label>
    <xdstring-value>MRN-12345</xdstring-value>
  </sdc4:ms-rx7b3e6h12197>
  <sdc4:ms-sy8c4f7i23208>
    <label>Birth Date</label>
    <xdtemporal-value>1985-05-15</xdtemporal-value>
  </sdc4:ms-sy8c4f7i23208>
</sdc4:ms-qw6a2d5g01186>

2025: Hospital wants to add genomic data (hypothetical SDC5 feature)

<!-- Old patient data still works (SDC4 namespace) -->
<sdc4:ms-qw6a2d5g01186 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Patient Record</label>
  <sdc4:ms-rx7b3e6h12197>
    <label>MRN</label>
    <xdstring-value>MRN-12345</xdstring-value>
  </sdc4:ms-rx7b3e6h12197>
  <sdc4:ms-sy8c4f7i23208>
    <label>Birth Date</label>
    <xdtemporal-value>1985-05-15</xdtemporal-value>
  </sdc4:ms-sy8c4f7i23208>
</sdc4:ms-qw6a2d5g01186>

<!-- New patient data uses SDC5 types -->
<sdc5:ms-tz9d5g8j34219 xmlns:sdc5="https://semanticdatacharter.com/ns/sdc5/">
  <label>Patient Record v2</label>
  <sdc5:ms-rx7b3e6h12197><!-- Reused component -->
    <label>MRN</label>
    <xdstring-value>MRN-67890</xdstring-value>
  </sdc5:ms-rx7b3e6h12197>
  <sdc5:ms-sy8c4f7i23208><!-- Reused component -->
    <label>Birth Date</label>
    <xdtemporal-value>2020-03-10</xdtemporal-value>
  </sdc5:ms-sy8c4f7i23208>
  <!-- New SDC5 type -->
  <sdc5:ms-ua0e6h9k45220>
    <label>Genome Sequence</label>
    <xdgenome-value>ATCG...</xdgenome-value>
  </sdc5:ms-ua0e6h9k45220>
</sdc5:ms-tz9d5g8j34219>

Query "All Patients":

//*[label='Patient Record' or label='Patient Record v2']

Returns: Both SDC4 and SDC5 patients, no migration needed!

Scenario 2: Government Agency Data Archive

2015: Agency stores NIEM Justice data in SDC4

<!-- Schema annotation links to NIEM 4.0 vocabulary -->
<sdc4:ms-vb1f7j0l56231 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Arrest Activity</label>
  <sdc4:ms-wc2g8k1m67242>
    <label>Arrest ID</label>
    <xdstring-value>ARR-2015-001</xdstring-value>
  </sdc4:ms-wc2g8k1m67242>
  <sdc4:ms-xd3h9l2n78253>
    <label>Arrest Date</label>
    <xdtemporal-value>2015-06-15</xdtemporal-value>
  </sdc4:ms-xd3h9l2n78253>
</sdc4:ms-vb1f7j0l56231>
<!-- Note: Schema annotations would include:
     <rdfs:isDefinedBy rdf:resource="http://niem.gov/niem-core/4.0/ArrestActivity"/> -->

2020: Agency adopts new NIEM 5.0 structures in SDC4

<!-- New Cluster version with updated semantic reference -->
<sdc4:ms-ye4i0m3o89264 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Arrest Activity v2</label>
  <sdc4:ms-wc2g8k1m67242><!-- Reused component -->
    <label>Arrest ID</label>
    <xdstring-value>ARR-2020-042</xdstring-value>
  </sdc4:ms-wc2g8k1m67242>
  <sdc4:ms-xd3h9l2n78253><!-- Reused component -->
    <label>Arrest Date</label>
    <xdtemporal-value>2020-08-22</xdtemporal-value>
  </sdc4:ms-xd3h9l2n78253>
</sdc4:ms-ye4i0m3o89264>
<!-- Schema annotation would reference NIEM 5.0:
     <rdfs:isDefinedBy rdf:resource="http://niem.gov/niem-core/5.0/ArrestActivity"/> -->

2025: Agency transitions to SDC5

<!-- SDC5 namespace with NIEM 6.0 semantic reference -->
<sdc5:ms-zf5j1n4p90275 xmlns:sdc5="https://semanticdatacharter.com/ns/sdc5/">
  <label>Arrest Activity v3</label>
  <sdc5:ms-wc2g8k1m67242><!-- Same component, SDC5 namespace -->
    <label>Arrest ID</label>
    <xdstring-value>ARR-2025-103</xdstring-value>
  </sdc5:ms-wc2g8k1m67242>
  <sdc5:ms-xd3h9l2n78253><!-- Same component, SDC5 namespace -->
    <label>Arrest Date</label>
    <xdtemporal-value>2025-11-03</xdtemporal-value>
  </sdc5:ms-xd3h9l2n78253>
</sdc5:ms-zf5j1n4p90275>
<!-- Schema annotation: NIEM 6.0 reference -->

Historical Query (10 years of data, component-based):

//*[local-name()='ms-xd3h9l2n78253']/xdtemporal-value

Alternative Query (label-based):

//*[label='Arrest Date']/xdtemporal-value

Returns: All arrest dates from 2015 (SDC4/NIEM 4.0), 2020 (SDC4/NIEM 5.0), 2025 (SDC5/NIEM 6.0) without any data transformation! The arrest date component (ms-xd3h9l2n78253) is reused across all versions and namespaces.

Scenario 3: International Standards Convergence

Organization: Global health initiative tracking diseases

Current State:

North America: FHIR-based systems
Europe: Mix of FHIR and local standards
Asia: Local standards
Africa: Mix of local and international standards

With SDC4:

North America Data (2020, FHIR-based) - Schema:

<!-- ComplexType for Disease Case Cluster (mc-ag1k2m5p12286) -->
<xsd:complexType name="mc-ag1k2m5p12286">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-ag1k2m5p12286">
        <rdfs:label>Disease Case</rdfs:label>
        <rdfs:isDefinedBy rdf:resource="http://hl7.org/fhir/Observation"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:ClusterType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Disease Case"/>
        <xsd:element ref="sdc4:ms-bh2l3n6q23297"/><!-- Disease Name -->
        <xsd:element ref="sdc4:ms-ci3m4o7r34308"/><!-- Diagnosis Date -->
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

North America Instance:

<sdc4:ms-ag1k2m5p12286 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Disease Case</label>
  <sdc4:ms-bh2l3n6q23297>
    <label>Disease Name</label>
    <xdstring-value>Malaria</xdstring-value>
  </sdc4:ms-bh2l3n6q23297>
  <sdc4:ms-ci3m4o7r34308>
    <label>Diagnosis Date</label>
    <xdtemporal-value>2020-03-15</xdtemporal-value>
  </sdc4:ms-ci3m4o7r34308>
</sdc4:ms-ag1k2m5p12286>

Asia Data (2022, local standard) - Schema with different semantic reference:

<!-- ComplexType for Disease Case - Asia version (mc-dj4n5p8s45319) -->
<xsd:complexType name="mc-dj4n5p8s45319">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-dj4n5p8s45319">
        <rdfs:label>Disease Case</rdfs:label>
        <rdfs:isDefinedBy rdf:resource="http://asia-health.org/diseaseReport"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:ClusterType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Disease Case"/>
        <xsd:element ref="sdc4:ms-bh2l3n6q23297"/><!-- Disease Name (reused) -->
        <xsd:element ref="sdc4:ms-ci3m4o7r34308"/><!-- Diagnosis Date (reused) -->
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

Asia Instance:

<sdc4:ms-dj4n5p8s45319 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Disease Case</label>
  <sdc4:ms-bh2l3n6q23297><!-- Same component as North America -->
    <label>Disease Name</label>
    <xdstring-value>Dengue Fever</xdstring-value>
  </sdc4:ms-bh2l3n6q23297>
  <sdc4:ms-ci3m4o7r34308><!-- Same component as North America -->
    <label>Diagnosis Date</label>
    <xdtemporal-value>2022-07-22</xdtemporal-value>
  </sdc4:ms-ci3m4o7r34308>
</sdc4:ms-dj4n5p8s45319>

Europe Data (2024, FHIR R5) - Schema with updated FHIR reference:

<!-- ComplexType for Disease Case - Europe version (mc-ek5o6q9t56320) -->
<xsd:complexType name="mc-ek5o6q9t56320">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-ek5o6q9t56320">
        <rdfs:label>Disease Case</rdfs:label>
        <rdfs:isDefinedBy rdf:resource="http://hl7.org/fhir/R5/Observation"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:ClusterType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Disease Case"/>
        <xsd:element ref="sdc4:ms-bh2l3n6q23297"/><!-- Disease Name (reused) -->
        <xsd:element ref="sdc4:ms-ci3m4o7r34308"/><!-- Diagnosis Date (reused) -->
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

Europe Instance:

<sdc4:ms-ek5o6q9t56320 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Disease Case</label>
  <sdc4:ms-bh2l3n6q23297><!-- Same component across all regions -->
    <label>Disease Name</label>
    <xdstring-value>COVID-19</xdstring-value>
  </sdc4:ms-bh2l3n6q23297>
  <sdc4:ms-ci3m4o7r34308><!-- Same component across all regions -->
    <label>Diagnosis Date</label>
    <xdtemporal-value>2024-01-10</xdtemporal-value>
  </sdc4:ms-ci3m4o7r34308>
</sdc4:ms-ek5o6q9t56320>

Global Query (component-based):

//sdc4:ms-bh2l3n6q23297/xdstring-value

Alternative Query (label-based):

//*[label='Disease Name']/xdstring-value

Returns: All disease cases (Malaria, Dengue Fever, COVID-19) across all regions (North America, Asia, Europe), all standards (FHIR, local, FHIR R5), all years (2020, 2022, 2024).

Key Insight: The Disease Name component (ms-bh2l3n6q23297) and Diagnosis Date component (ms-ci3m4o7r34308) are reused across all three Cluster versions (ms-ag1k2m5p12286, ms-dj4n5p8s45319, ms-ek5o6q9t56320). Each Cluster has different semantic references (FHIR, Asia-Health, FHIR R5) but shares the same structural components. No integration layer needed—structural convergence (XdStringType, XdTemporalType) enables direct querying across semantic diversity.

Conclusion: Data Immortality

The Core Breakthrough

Traditional Standards (FHIR, NIEM, HL7 V2, X12):

Semantics + Structure → Version Change → Forced Migration → Data Death (transform or abandon)

SDC4:

Structure (stable) ⊥ Semantics (evolving) → No Breaking Changes → Data Immortality

Three Guarantees

Structural Stability: Xd*Types rarely change; when they do, new namespace allows coexistence
Semantic Evolution: Ontology URIs change freely without structural impact
Query Continuity: XPath works across versions because structural patterns are preserved

The Vision

2025: Hospital implements SDC4 with Patient Name component (ms-fl6p7s0u67331)

2050: SDC7 exists

Query from 2050 (component-based, namespace-agnostic):

//*[local-name()='ms-fl6p7s0u67331']/xdstring-value

Alternative Query (label-based):

//*[label='Patient Name']/xdstring-value

Returns:

Patient names from 2025 (SDC4 namespace)
Patient names from 2035 (SDC5 namespace)
Patient names from 2045 (SDC6 namespace)
Patient names from 2050 (SDC7 namespace)

No Migration Ever: 25 years of data, always accessible, always queryable, always computable. The Patient Name component (ms-fl6p7s0u67331) is reused across all SDC versions, with namespace being the only difference.

This is the promise of separation of concerns. This is data immortality.

Next Steps

For understanding versioning in specific standards:

FHIR Datatypes Analysis - See Section on "Versioning Challenges"
NIEM Semantics Problem - See "Technical Debt Accumulation"

For strategic implications:

NIEM Government-Wide Vision - See "Economic Impact" section

For implementation:

NIEM Quick Reference - Component versioning patterns

Document Navigation:

← FHIR Integration | NIEM Integration →

About This Documentation

This document describes the open SDC4 specification maintained by the Semantic Data Charter community.

Open Source:

Specification: https://semanticdatacharter.com
GitHub: https://github.com/SemanticDataCharter
License: CC BY 4.0

Commercial Implementation:

SDCStudio: https://axius-sdc.com (by Axius SDC, Inc.)

See ABOUT_SDC4_AND_SDCSTUDIO.md for details.

*This document is part of the SDC4 Integration Guide series.*

*Author: Timothy W. Cook (Founder, Axius SDC, Inc.) w/Claude (Anthropic AI Assistant)*

*License: Creative Commons Attribution 4.0 International (CC BY 4.0)*

Executive Summary

Table of Contents

The Versioning Problem in FHIR

FHIR R4 → R5 Migration Reality

FHIR Version Migration Costs

Why FHIR Can't Avoid This

The Versioning Problem in NIEM

NIEM 4.0 → 5.0 Migration Reality

NIEM Breaking Changes Example

NIEM Migration Costs

Why NIEM Can't Avoid This

Why Coupling Semantics and Structure Forces Migration

The Fundamental Problem

The Migration Cascade

The Technical Debt Accumulation

SDC4's Revolutionary Approach

Core Principle: Structural Stability + Semantic Evolution

Component Versioning with CUID2

The CUID2 Strategy

XPath Continuity and Query Stability

The XPath Guarantee

Query Evolution Example

SDC4 ↔ SDC5 Coexistence

Reference Model Evolution

Economic Impact of Data Immortality

The Migration Tax

Comparative Analysis

Hidden Benefits

Real-World Scenarios

Scenario 1: Healthcare System Evolution

Scenario 2: Government Agency Data Archive

Scenario 3: International Standards Convergence

Conclusion: Data Immortality

The Core Breakthrough

Three Guarantees

The Vision

Next Steps

About This Documentation