Built on 16+ International Standards • W3C • ISO • IETF

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.

HIPAA/GDPR Ready
Export to 7+ Formats
AI-Ready Data

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.

XSD • SHACL • ISO 27001

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.

RDF • OWL • SPARQL

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.

ISO 21090 • ISO 8601 • WGS 84

STANDARDS-COMPLIANT ARCHITECTURE

W3C Standards
ISO/IEC Standards
IETF Protocols
HL7/OMG

Self-Describing Interoperability Architecture

Schemas that carry their semantics, validation rules, and ontological mappings—enabling recipients to process data without prior coordination

🔗

Embedded Semantics

RDF/OWL ontology links in XSD annotations
JSON-LD context for linked data integration
GQL property graph schemas for traversal
<xs:annotation>
  <xs:appinfo>
    <rdf:type rdf:resource="
      http://example.org/Patient"/>
  </xs:appinfo>
</xs:annotation>

Validation Rules

SHACL shapes for graph validation
XSD constraints for structural validation
SPARQL-based business rules
sh:property [
  sh:path ex:patientId ;
  sh:datatype xsd:string ;
  sh:pattern "^P[0-9]{6}$" ;
  sh:minCount 1 ;
] .
🕸

Graph Structures

RDF triple extraction for semantic web
GQL CREATE statements for property graphs
SPARQL endpoint integration
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

✓ SNOMED CT/LOINC ontology links
✓ HL7 V3 compatibility via RDF
✓ Provenance tracking via W3C PROV

Supply Chain

Manufacturers share shipment data with GS1-aligned product ontologies and geospatial validation

✓ GS1 Web Vocabulary integration
✓ WGS84 geo coordinates in RDF
✓ EPCIS event ontology mapping

Research Collaboration

Labs publish experimental results with domain-specific ontologies and reproducibility metadata

✓ Custom domain ontology links
✓ DCAT-compliant dataset metadata
✓ DOI/ORCID provenance tracking

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 Specification

Permanence 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

  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><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

  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><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

Introducing SDC Studio

Build semantic data models using familiar tools—no technical expertise required. From markdown templates to production-ready schemas in minutes.

1

Design with Obsidian

Use markdown templates in Obsidian

Templater plugin guides you through

Define types, constraints, relationships

No XML or schema knowledge required

2

AI Processing

Upload markdown or CSV files

Multi-agent AI detects types

Infers constraints, clusters fields

Links to SNOMED, LOINC, WikiData

3

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.

User-friendly data types (text, integer, date)
Automatic intelligent type mapping
Optional LLM enrichment for semantics
## Column: patient_age
Type: integer
Units: years
Description: Patient age at visit
Constraints:
- required: true
- range: [0, 120]
→ Mapped to XdCount (SDC4)

Then Let AI Build Your Application

From data model to production-ready app in one conversation

⚡ NEW: VIBE CODING ON STEROIDS

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.

Framework Agnostic: Choose Python Reflex, React, Django, FastAPI, or anything else
Standards-Based Validation: Optional sdcvalidator library for full SDC4 compliance including ExceptionValue handling
Complete Package: XSD schema, XML/JSON instances, HTML docs, SHACL shapes, and ready-to-use AI prompt
Minimal SDC4 Knowledge Required: Domain experts design, AI assistants build, standards ensure quality
README-AI-PROMPT.md (included in every download)
$ unzip customer-data.zip
// 📦 dm-*.xsd, dm-*.xml, dm-*.json, dm-*.html...
// 📦 README-AI-PROMPT.md
→ Paste README into Claude/ChatGPT/Gemini
→ Attach your schema files
→ Specify your requirements
✓ Production app in one conversation
🎯 The Vibe Coding Revolution
Traditional Vibe Coding:
"Build me a customer database" → AI invents structure → 10 iterations → mediocre result
With SDC Studio:
Formal model + AI prompt → Standards-compliant structure → Database mappings → Validation rules → ONE iteration → production quality
The Invisible Excellence:
SDC4 standards work behind the scenes. Your team gets interoperable, validated, semantic-rich apps without knowing SDC exists.

Domain experts design models. AI assistants build applications. Standards ensure quality. Reduced technical debt.

Supports Claude, ChatGPT, Gemini, Copilot, and any LLM-assisted coding tool

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.

16+
International Standards
W3C, ISO, IETF compliance
15
Exceptional Value Types
ISO 21090 NULL Flavors
7
W3C Standards
RDF, OWL, SPARQL, SHACL
Full
Semantic Interoperability
Machine-readable metadata

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

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.

IN DEVELOPMENT

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 Organization

github.com/SemanticDataCharter

Ready 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