Standards-Based Data Architecture.
Reduced ETL Complexity.
The Semantic Data Charter™ enables true interoperability through comprehensive standards compliance. Stop building custom integrations. Start leveraging RDF, OWL, SPARQL, and 13+ other standards to create data that speaks every system's language—natively.
The Standards-Enabled Solution
Instead of building another fragile ETL pipeline, leverage decades of standards work. SDC implements the complete W3C Semantic Web stack, ISO healthcare informatics standards, and IETF protocols—giving you interoperability out of the box.
The Old Way: Custom ETL Hell
Every new system integration requires custom code. Data mappings break. Field names conflict. Your team spends months on "one-off" transformations that become permanent technical debt.
Standards-Enabled: RDF + OWL + SPARQL
Your data is already RDF. Any system that speaks W3C standards can consume it directly. Need to query across datasets? SPARQL is built-in. Want semantic relationships? OWL ontologies are native. Minimal custom integration code required.
The Old Way: Missing/Invalid Data = Silent Failure
Bad data gets dropped, or worse—corrupted values pass validation. You lose critical information and have no audit trail explaining what happened or why.
Standards-Enabled: ISO 21090 NULL Flavors
15 standardized exceptional value types. "Not applicable" vs. "asked but unknown" vs. "masked for privacy"—each has its own ISO-defined semantic meaning. Data quality issues are tagged, preserved, and traceable. Healthcare interoperability standard adopted across industries.
The Old Way: API Lock-In
REST? GraphQL? gRPC? SOAP? Each consumer wants a different API. You build and maintain multiple endpoints for the same data, each with custom documentation and versioning nightmares.
Standards-Enabled: Multi-Format Export
One model, seven output formats. Auto-generate XSD schemas, JSON-LD, RDF/Turtle, SHACL shapes, GraphQL schemas, and more. Your data speaks every format natively because it's built on standards, not proprietary APIs.
The Old Way: Compliance Theater
HIPAA, GDPR, NIST—you bolt on security tags as an afterthought. Auditors ask "where's the field-level access control?" and you scramble to retrofit compliance into your schema.
Standards-Enabled: Built-In Governance
Every data element has metadata. Access control tags (HIPAA, GDPR, NIST), geolocation (WGS 84), temporal validity (ISO 8601), language tags (RFC 5646)—all baked into the reference model. Compliance is architectural, not aspirational.
This Is What Standards-Based Architecture Looks Like
Stop reinventing the wheel. The W3C, ISO, and IETF already solved your interoperability problems. SDC gives you the implementation—ready to deploy.
Three Pillars. All Standards-Based.
Not just theory. Every capability is powered by international standards that major enterprises already use.
Standards-Based Governance
XSD 1.1 schemas + SHACL validation = machine-enforceable rules. Field-level access control tags aligned with HIPAA, GDPR, and NIST standards. Compliance is built-in, not bolted on.
Standards-Based Semantics
RDF triples + OWL ontologies = data that machines understand. Link to SNOMED CT, LOINC, ICD-10, or any ontology. Query across systems with SPARQL. True semantic interoperability.
Standards-Based Quality
ISO 21090 NULL Flavors = 15 standardized ways to handle exceptions. ISO 8601 temporal precision. WGS 84 geolocation. Every data element has metadata. No silent failures.
STANDARDS-COMPLIANT ARCHITECTURE
Self-Describing Interoperability Architecture
Schemas that carry their semantics, validation rules, and ontological mappings—enabling recipients to process data without prior coordination
Embedded Semantics
<xs:annotation>
<xs:appinfo>
<rdf:type rdf:resource="
http://example.org/Patient"/>
</xs:appinfo>
</xs:annotation>
Validation Rules
sh:property [
sh:path ex:patientId ;
sh:datatype xsd:string ;
sh:pattern "^P[0-9]{6}$" ;
sh:minCount 1 ;
] .
Graph Structures
CREATE (p:Patient {
id: "P000123",
type: "http://ex.org/Patient"
})
-[:HAS_OBSERVATION]->(o:Obs)
Implementation Patterns
Healthcare Network
Hospitals exchange patient observations with FHIR-aligned ontology mappings and HIPAA-compliant validation
Supply Chain
Manufacturers share shipment data with GS1-aligned product ontologies and geospatial validation
Research Collaboration
Labs publish experimental results with domain-specific ontologies and reproducibility metadata
Why Not Traditional EDI or Vendor Formats?
❌ Traditional EDI (X12, EDIFACT)
- • Fixed message types—slow evolution
- • No semantic interoperability
- • Proprietary implementations
- • High integration costs per partner
✅ SDC4 Self-Describing Models
- • Extensible via W3C standards (RDF/OWL)
- • Embedded ontology mappings
- • Open specification—no vendor lock-in
- • Recipients auto-validate and interpret
Key Advantage: Organizations define models on THEIR schedule—no waiting for standards bodies or vendor roadmaps
Read Technical SpecificationPermanence Architecture: Designed for Long-Term Data Persistence
CUID-based immutability + namespace versioning designed to reduce migration burdens
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>→<bp>breaks compatibility, CUID remains stable
Instance Data (2025)
<dm-h7k2x... xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
<sdc4:ms-clj5x1g8f000008l09j7f6c3d>
<sdc4:ms-clj5x2p4k000108l01a2b3c4d>
<sdc4:xdquantity-value>120</sdc4:xdquantity-value>
<sdc4:xdquantity-units>
<sdc4:xdstring-value>mmHg</sdc4:xdstring-value>
</sdc4:xdquantity-units>
</sdc4:ms-clj5x2p4k000108l01a2b3c4d>
</sdc4:ms-clj5x1g8f000008l09j7f6c3d>
</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> → <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 ❌ $500K-$5M cost |
✅ v1 + v2 coexist ✅ Reduced migration burden |
| 20-Year Data Lifecycle |
❌ 4-6 migrations ❌ $5M-$25M total cost ❌ Data loss risk each time |
✅ Minimal migrations ✅ Reduced migration costs ✅ Lower data loss risk |
See the Architecture in Action
Introducing SDC Studio™
Build semantic data models using familiar tools—no technical expertise required. From markdown templates to production-ready schemas in minutes.
Design with Obsidian
Use markdown templates in Obsidian
Templater plugin guides you through
Define types, constraints, relationships
No XML or schema knowledge required
AI Processing
Upload markdown or CSV files
Multi-agent AI detects types
Infers constraints, clusters fields
Links to SNOMED, LOINC, WikiData
Generate & Deploy
XSD schemas for validation
RDF triples for semantic web
SHACL validation shapes
JSON schemas, GraphQL, and more
Start with Simple Markdown
Write data models in plain markdown. Our Obsidian templates guide you through every field, turning your domain knowledge into production-ready schemas.
Then Let AI Build Your Application
From data model to production-ready app in one conversation
Your Data Model is the Perfect AI Prompt
Download your SDC package, paste our conversation starter into any LLM (Claude, ChatGPT, Gemini), and watch it generate a production-quality application—automatically conforming to your exact data model with validation, constraints, and semantic metadata built-in.
🎯 The Vibe Coding Revolution
Domain experts design models. AI assistants build applications. Standards ensure quality. Reduced technical debt.
Built for Demanding Industries
From regulatory compliance to complex system integration, the Semantic Data Charter™ is the solution for organizations where data integrity is not optional.
Healthcare & Life Sciences
Harmonize patient data from different systems, ensure clinical trial data integrity, and create a single view of research findings while enforcing strict governance.
Finance & Insurance
Achieve true data lineage for regulatory reporting (e.g., BCBS 239), build comprehensive customer-360 models, and power next-generation fraud detection systems.
Advanced Manufacturing
Create a "digital twin" of your supply chain, unify sensor data from IoT devices, and build a knowledge graph to optimize production and predictive maintenance.
Built on International Standards
The Semantic Data Charter™ implements comprehensive compliance with W3C, ISO, IETF, and industry standards, ensuring interoperability, governance, and future-proofing.
W3C Semantic Web Stack
- ✓ RDF 1.1 - Semantic triples
- ✓ OWL 2 - Ontology definitions
- ✓ SPARQL 1.1 - Semantic queries
- ✓ SHACL 1.0 - Constraint validation
- ✓ XSD 1.1 - Schema definitions
ISO/IETF Standards
- ✓ ISO 21090 - Data type harmonization
- ✓ ISO 8601 - Temporal precision
- ✓ RFC 3066/5646 - Language tags
- ✓ IANA - Character sets & MIME types
- ✓ WGS 84 - Geographic coordinates
Regulatory Compliance
- ✓ HIPAA - PHI protection
- ✓ GDPR - Personal data governance
- ✓ NIST 800-53 - Security controls
- ✓ 21 CFR Part 11 - Electronic records
- ✓ FedRAMP - Cloud security
Research & Background Materials
Explore the science and theory behind the Semantic Data Charter™ with our collection of research papers and interactive visualizations.
Neuro-Symbolic AI Infographic
Discover how Neuro-Symbolic AI and the Semantic Data Charter™ converge to create explainable, trustworthy artificial intelligence.
View Interactive →Pathway to Explainable AI
A comprehensive research paper examining how semantic data governance enables transparent and verifiable artificial intelligence systems.
Download PDF →Outliers: Noise or Discovery?
Learn how formal data governance helps distinguish between data errors and potentially groundbreaking discoveries in exceptional values.
Download PDF →Our Open Source Contributions
We believe the foundation of data trust should be open, accessible, and community-driven.
SDC4 Reference Model
Open Standard Specification
The Semantic Data Charter 4.0 (SDC4) is our open source reference model that defines how data should be structured, validated, and enriched with semantic meaning. Built on 16+ international standards including W3C RDF, OWL, SHACL, and ISO 21090.
sdcvalidator
Python Validation Library
A production-ready Python library for validating XML data against SDC4-compliant schemas. Supports ExceptionValue patterns for justified constraint violations, enhanced error messages, and complete SDC4 validation beyond standard XML Schema.
sdcvalidatorJS
TypeScript/Node.js Library
TypeScript/Node.js implementation of SDC4 validation with ExceptionalValue recovery. Features pattern-based error classification, CLI tool (sdcvalidate), and full TypeScript support. Currently achieving 90.4% test coverage with 182 tests.
Free Forever. The SDC4 reference model and our validation libraries are open source and will always be freely available to the community.
Explore All Our Open Source Projects
Visit our GitHub organization to see all repositories, contribute, report issues, and join the community building the future of trusted data.
Visit GitHub OrganizationReady to Build a Foundation of Trust?
Stop managing data chaos. Start building your Semantic Data Charter™ today. No credit card required.
Sign Up for SDC Studio™About Axius SDC
The Semantic Data Charter is developed by Axius SDC, Inc., an international team with 40+ years combined experience in semantic data and health informatics across the United States, Canada, and Brazil.
Learn more about our team