Publishing and Generating Outputs

Reading time: ~6 minutes | Level: Intermediate Prerequisites: Walkthrough 2: SDCStudio Overview

What You'll Learn

  • Why publication is irreversible and what that means for your workflow
  • The required publication order: components, then clusters, then the model
  • How to generate the output package (one-time operation)
  • What output files are produced and what each one is for
  • What to do if you need changes after publishing

Why Publication is Irreversible

Publication is a core principle of the Semantic Data Charter, not just a software feature. When you publish a component or model:

  • Its definition becomes permanent and immutable
  • Any data validated against it will always be interpretable
  • The CUID-based identifiers (mc-... and ms-...) become fixed references
  • Other models can safely import and reuse published components

This immutability is what makes SDC4 data long-lived. If published schemas could change, data validated against them would become unreliable.

The practical consequence: Verify everything is correct before publishing. Use Save (draft) freely while working. Only use Save & Publish when you are certain. There is no Unpublish, and published items cannot be deleted.

The Publication Order

Publication must follow a bottom-up order, and SDCStudio enforces it:

1. Publish all child components     (Save & Publish on each)
2. Publish the cluster              (refused while any member is unpublished)
3. Publish the data model           (refused while its Data cluster is unpublished)
4. Generate the output package      (Generate button, one-time)

Step 1: Publish Child Components

For each component in your model:

  1. Open Components (/app/components)
  2. Open the component's detail page
  3. Click Edit
  4. Go to the Review & Save step
  5. Click Save & Publish (shown to the project owner and admins only). It acts immediately; there is no confirmation dialog

Repeat for every component. Check that all components show the "Published" badge before proceeding. Then open the cluster, click Edit Cluster, and use Save & Publish the same way.

Step 2: Publish the Data Model

A draft model with its Publish button

  1. Open Data Models (/app/models)
  2. Click your model to open its detail page (the list also has a Publish link on each draft row)
  3. Click the Publish button on the model detail page (owner and admins only). It acts immediately; there is no confirmation dialog

The model status changes from Draft to Published. The Publish button disappears; this action can only be done once. If the Data cluster is still unpublished, the publish is refused with a message saying so.

Step 3: Generate the Output Package

A published model with its Generate button

After publishing the model, a Model Generation card appears on the model detail page:

  1. Click Generate (free; only Download App, further down, is charged)
  2. SDCStudio generates all output files in a single operation
  3. The button becomes Download Complete Package (ZIP)

This is also a one-time operation. Once generated, the package cannot be regenerated.

Output Files

The ZIP package includes:

File Format Purpose
dm-{id}.xsd XML Schema Structural validation; use this to validate XML data
dm-{id}.xml XML template The Governed Data Record with a placeholder at every value; validates once filled
dm-{id}-instance.json JSON Complete data example mirroring the XML structure
dm-{id}.jsonld JSON-LD Semantic description for linked data integration
dm-{id}.html HTML Human-readable documentation for review and sharing
dm-{id}.rdf RDF/XML Extracted triples for triple stores and knowledge graphs
dm-{id}.ttl Turtle The same triples in Turtle
dm-{id}_shacl.ttl SHACL (Turtle) Shape constraints for RDF data validation
dm-{id}.gql GQL CREATE statements for property graph databases
dm-{id}.sha1 SHA-1 hash Integrity check of the XSD
SHACL_README.md Markdown How to run the SHACL shapes
README-AI-PROMPT.md Markdown A prompt describing the package for AI tools

When to Use Each Format

After generation: the Model Generation card lists the package

XSD + XML: When you need to validate XML data or provide XML-based integration.

JSON Instance: When building REST APIs, JavaScript applications, or any JSON-based system.

JSON-LD: When integrating with semantic web systems, knowledge graphs, or linked data platforms.

HTML: When sharing documentation with stakeholders, training materials, or compliance reviews.

RDF: When loading data descriptions into triple stores (like Apache Jena Fuseki) for SPARQL queries.

SHACL: When you need RDF constraint validation, ensuring RDF data conforms to your model's rules.

GQL: When working with property graph databases like Neo4j.

Downloading Outputs

The single Download Complete Package (ZIP) button

After generation there is one download: Download Complete Package (ZIP) on the Model Generation card. There are no per-file downloads; unpack the ZIP to get the individual files.

Once the package exists, a second card, Generate App (choose one), offers a Lightweight or Enterprise application build for the model. After the build finishes, Download App fetches it. The first download of a model, either profile, costs 1,500 credits; later downloads of it are free, and a revised model is a new model.

Save your downloads and store them in a safe location.

What If You Need Changes?

Published items cannot be edited, unpublished or deleted. If you discover an issue after publishing:

  1. Copy the published component or model (the Copy button on its detail page). This creates an unpublished item labeled "COPY -- ..." that records its origin with prov:wasDerivedFrom. Copy is refused for retired sources
  2. Rename the copy; the "COPY -- " prefix blocks publishing until you do
  3. Edit the copy with the corrections applied
  4. Test thoroughly: verify everything before publishing again
  5. Publish the copy, following the same bottom-up order
  6. Retire the earlier item (owner and admins only) once nothing new should use it. A retired item stays published and resolvable by its identifier; it is only removed from the lists

Versioning strategy: Use version indicators in model titles (for example "CustomerModel v1", "CustomerModel v2"). Document what changed in the description. The retired model remains a permanent historical record.

Pre-Publication Checklist

Before publishing, verify:

  • [ ] All component labels are accurate and descriptive
  • [ ] All descriptions explain what each component represents
  • [ ] Data types are correct for each component
  • [ ] Validation rules (patterns, ranges, enumerations) are tested
  • [ ] Units are specified for all quantified types (XdCount, XdQuantity, XdFloat, XdDouble)
  • [ ] Semantic links are in place for core components
  • [ ] Cluster organization reflects the logical data structure
  • [ ] All stakeholders have reviewed the model

Summary

  • Publication is one-time and irreversible; it makes components and models permanent
  • Publish in order: components first, then the cluster, then the model, then generate the package
  • The package is one ZIP, generated in a single operation (also one-time)
  • If changes are needed after publishing, Copy, fix, publish, and Retire the old one

Next walkthrough

Working with Models and Projects covers how to create models from scratch, organize projects, and plan your versioning strategy.