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
- Permanent Structure:
mc-clj5x1g8f000008l09j7f6c3dalways means the same physical structure - Fixed Semantics:
label="Blood Pressure"is immutable in the schema - Queryable by CUID: Applications query
ms-clj5x1g8f000008l09j7f6c3d, guaranteed to find the same structure - 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
- Separate Namespaces: SDC4 and SDC5 have distinct URIs - no name collision
- XML Schema Imports: Applications can import both schemas simultaneously
- RDF Named Graphs: Triplestores partition by namespace, enabling federated queries
- 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
Patient demographics, vitals, lab results
Namespace: .../sdc4/
(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/
20% SDC5 data (genomics), 80% SDC4 data (legacy vitals)
Federated SPARQL queries across both
(AI-enhanced semantic links)
- SDC4 + SDC5 data still operating
- Gradual SDC6 adoption for new use cases
Namespaces: .../sdc4/ + .../sdc5/ + .../sdc6/
Original 2025 SDC4 data: validates against SDC4 schemas, queryable via SPARQL
SDC4 models designed for long-term stability - minimal migration burden
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 |