Permanence Architecture

CUID-based immutability and namespace versioning designed to reduce migration burdens and enable long-term data persistence.

Dual-Layer Permanence Architecture

+-----------------------------------------------------+
|           Layer 2: Namespace Versioning              |
|  (Cross-Version Coexistence: SDC4 - SDC5 - SDC6)    |
+-----------------------------------------------------+
|  https://semanticdatacharter.com/ns/sdc4/            |
|  https://semanticdatacharter.com/ns/sdc5/            |
|  https://semanticdatacharter.com/ns/sdc6/            |
+-----------------------------------------------------+
         ^                 ^                 ^
         |                 |                 |
+--------+-----+  +-------+------+  +-------+------+
| Layer 1:     |  | Layer 1:     |  | Layer 1:     |
| CUID-Based   |  | CUID-Based   |  | CUID-Based   |
| Immutability |  | Immutability |  | Immutability |
| (Within V4)  |  | (Within V5)  |  | (Within V6)  |
+--------------+  +--------------+  +--------------+

Layer 1: Immutable Structural Components

Problem Solved: Within-version model immutability - create new models without migrating old data

The Mechanism

SDC4 decouples structure from semantics using CUID2 identifiers:

  • mc-<cuid>: Model Component type definition (structure)
  • ms-<cuid>: Model Structure element (instance)
  • label: Fixed semantic meaning (e.g., "Systolic Blood Pressure")

Schema Example: Immutable Blood Pressure Component

<!-- Defined once in 2025, designed for long-term persistence -->
<xsd:complexType name="mc-clj5x1g8f000008l09j7f6c3d">
  <xsd:complexContent>
    <xsd:restriction base="sdc4:ClusterType">
      <xsd:sequence>
        <!-- Semantic meaning is FIXED -->
        <xsd:element name="label" type="xsd:string"
                     fixed="Blood Pressure" />

        <!-- Structure references immutable systolic component -->
        <xsd:element ref="sdc4:ms-clj5x2p4k000108l01a2b3c4d"
                     minOccurs="1" maxOccurs="1" />

        <!-- Structure references immutable diastolic component -->
        <xsd:element ref="sdc4:ms-clj5x2p4k000108l01a2b3c4e"
                     minOccurs="1" maxOccurs="1" />
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<!-- Element declaration for substitution -->
<xsd:element name="ms-clj5x1g8f000008l09j7f6c3d"
             type="mc-clj5x1g8f000008l09j7f6c3d"
             substitutionGroup="sdc4:Item" />

Why This Prevents Migration

  1. Permanent Structure: mc-clj5x1g8f000008l09j7f6c3d always means the same physical structure
  2. Fixed Semantics: label="Blood Pressure" is immutable in the schema
  3. Queryable by CUID: Applications query ms-clj5x1g8f000008l09j7f6c3d, guaranteed to find the same structure
  4. No Name Dependency: Unlike traditional XML where <bloodPressure> to <bp> breaks compatibility, CUID remains stable

Instance Data (2025)

<sdc4:dm-h7k2x... xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <sdc4:dm-label>Patient Vitals</sdc4:dm-label>
  <sdc4:dm-language>en-US</sdc4:dm-language>
  <sdc4:dm-encoding>UTF-8</sdc4:dm-encoding>

  <sdc4:ms-clj5x1g8f000008l09j7f6c3d>
    <sdc4:label>Blood Pressure</sdc4:label>
    <sdc4:ms-clj5x2p4k000108l01a2b3c4d>
      <sdc4:label>Systolic</sdc4:label>
      <sdc4:xdquantity-value>120</sdc4:xdquantity-value>
      <sdc4:xdquantity-units>
        <sdc4:label>Units</sdc4:label>
        <sdc4:xdstring-value>mmHg</sdc4:xdstring-value>
      </sdc4:xdquantity-units>
    </sdc4:ms-clj5x2p4k000108l01a2b3c4d>
  </sdc4:ms-clj5x1g8f000008l09j7f6c3d>
</sdc4:dm-h7k2x...>

Same Data, Still Valid Against SDC4 Schemas in 2035

An application in 2035 can query 2025 SDC4 data using the SDC4 namespace:

# Query by CUID - guaranteed stable structure
bp_elements = doc.findall(".//sdc4:ms-clj5x1g8f000008l09j7f6c3d",
                           namespaces={'sdc4': 'https://semanticdatacharter.com/ns/sdc4/'})

for bp in bp_elements:
    # Structure is immutable, so this always works
    systolic = bp.find(".//sdc4:ms-clj5x2p4k000108l01a2b3c4d//sdc4:xdquantity-value")
    print(f"Systolic: {systolic.text} mmHg")

Result: Data from 2025 is designed to work in 2035 with minimal migration burden

Layer 2: Namespace Versioning

Problem Solved: Cross-version coexistence (SDC4, SDC5, SDC6...)

The Mechanism

Each SDC major version gets its own XML namespace URI:

  • SDC4: https://semanticdatacharter.com/ns/sdc4/
  • SDC5: https://semanticdatacharter.com/ns/sdc5/ (when released)
  • SDC6: https://semanticdatacharter.com/ns/sdc6/ (future)

Coexistence in XML Schema

<!-- SDC4 Schema (permanent) -->
<xs:schema
  xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/"
  targetNamespace="https://semanticdatacharter.com/ns/sdc4/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:complexType name="XdQuantityType">
    <!-- SDC4 definition -->
  </xs:complexType>
</xs:schema>

<!-- SDC5 Schema (coexists with SDC4) -->
<xs:schema
  xmlns:sdc5="https://semanticdatacharter.com/ns/sdc5/"
  targetNamespace="https://semanticdatacharter.com/ns/sdc5/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:complexType name="XdQuantityType">
    <!-- SDC5 definition (enhanced) -->
  </xs:complexType>
</xs:schema>

<!-- Application schema can import BOTH -->
<xs:schema
  xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/"
  xmlns:sdc5="https://semanticdatacharter.com/ns/sdc5/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:import namespace="https://semanticdatacharter.com/ns/sdc4/"
             schemaLocation="sdc4.xsd"/>
  <xs:import namespace="https://semanticdatacharter.com/ns/sdc5/"
             schemaLocation="sdc5.xsd"/>

  <!-- Use SDC4 components for legacy data -->
  <xs:element name="LegacyPatient" type="sdc4:DMType"/>

  <!-- Use SDC5 components for new data -->
  <xs:element name="EnhancedPatient" type="sdc5:DMType"/>
</xs:schema>

RDF Graph Partitioning

# Query SDC4 data only
SELECT ?patient ?age
FROM NAMED <https://semanticdatacharter.com/ns/sdc4/>
WHERE {
  GRAPH <https://semanticdatacharter.com/ns/sdc4/> {
    ?patient sdc4:hasAge ?age .
  }
}

# Federated query across SDC4 AND SDC5
SELECT ?patient ?ageSource ?age
WHERE {
  {
    GRAPH <https://semanticdatacharter.com/ns/sdc4/> {
      ?patient sdc4:hasAge ?age .
      BIND("SDC4" AS ?ageSource)
    }
  } UNION {
    GRAPH <https://semanticdatacharter.com/ns/sdc5/> {
      ?patient sdc5:hasAge ?age .
      BIND("SDC5" AS ?ageSource)
    }
  }
}

# Aggregate across all versions
SELECT ?ageSource (COUNT(?patient) AS ?count)
WHERE {
  {
    GRAPH <https://semanticdatacharter.com/ns/sdc4/> {
      ?patient sdc4:hasAge ?age .
      BIND("SDC4" AS ?ageSource)
    }
  } UNION {
    GRAPH <https://semanticdatacharter.com/ns/sdc5/> {
      ?patient sdc5:hasAge ?age .
      BIND("SDC5" AS ?ageSource)
    }
  } UNION {
    GRAPH <https://semanticdatacharter.com/ns/sdc6/> {
      ?patient sdc6:hasAge ?age .
      BIND("SDC6" AS ?ageSource)
    }
  }
}
GROUP BY ?ageSource

Why This Prevents Cross-Version Migration

  1. Separate Namespaces: SDC4 and SDC5 have distinct URIs - no name collision
  2. XML Schema Imports: Applications can import both schemas simultaneously
  3. RDF Named Graphs: Triplestores partition by namespace, enabling federated queries
  4. W3C Standards Foundation: XML namespaces are a core W3C standard providing long-term stability

Result: SDC4, SDC5, SDC6... designed to coexist with minimal cross-version migration

Example: Healthcare Network 2025-2045

2025
Deploy SDC4

Patient demographics, vitals, lab results

Namespace: .../sdc4/

2028
SDC5 Releases

(enhanced genomic data types)

  • SDC4 data continues operating - no migration
  • Build new genomic models in SDC5
  • Reuse SDC4 patient demographics via copy/edit

Namespaces: .../sdc4/ + .../sdc5/

2030
Running in Parallel

20% SDC5 data (genomics), 80% SDC4 data (legacy vitals)

Federated SPARQL queries across both

2033
SDC6 Releases

(AI-enhanced semantic links)

  • SDC4 + SDC5 data still operating
  • Gradual SDC6 adoption for new use cases

Namespaces: .../sdc4/ + .../sdc5/ + .../sdc6/

2045
20 Years Later

Original 2025 SDC4 data: validates against SDC4 schemas, queryable via SPARQL

SDC4 models designed for long-term stability - minimal migration burden

Migration approach
Reduced burden
Benefit
Lower costs

Why Traditional Approaches Fail

Challenge Traditional XML/JSON SDC Permanence Architecture
Element Rename <bloodPressure> to <bp>
Breaks all XPath queries
Requires data migration
ms-clj5x1g8f... (immutable CUID)
Query by CUID, not name
No migration needed
Need New Structure Change schema - old data invalid
ETL pipeline to migrate
Create new model (new CUID)
Old data + old model remain valid
Major Version Upgrade Forced migration project
Significant cost
v1 + v2 coexist
Reduced migration burden
20-Year Data Lifecycle 4-6 migrations
High total cost
Data loss risk each time
Minimal migrations
Reduced migration costs
Lower data loss risk