Schema Standardsstandard

Connect ShEx

Keep the four assertions in every shape constraint from dying in a hand copy.

How CoreModels works with ShEx

ShEx is denser than it looks. Teams translating shapes into application schemas flatten IRIs into strings and `{1,1}` into “required” with no record of the loss.

CoreModels decodes ShEx into the neutral model and encodes out with a ledger. Re-import the authoritative shapes and audit the generated schemas so a cardinality change in ShExC is a CI finding, not a silent API change.

Use this when RDF shapes are the contract and JSON/SQL are the runtime — and you need both to stay honest about what they cannot express.

Recipes

No recipes yet for ShEx. The articles below still describe the problem this connector is built to close.

Uses

Problems this connector fixes

Articles that explain the gap, then point at the recipe that closes it.

Problem

Four Facts in a Line: What Hand-Copied Shapes Throw Away

Read one triple constraint out of a ShExC file: a predicate, a value constraint, a cardinality marker, a semicolon. It looks like a field declaration. It is denser than that.

Outcomes

Tuesday, 09:40: A Week in Which Shapes Are Just Another Export

The clearest way to describe an after-state is to timestamp it. Here is a week in a team that has stopped maintaining a second copy of its model — where a partner's shapes are an input, the warehouse DDL is an output, and the return submission is a diff. Nothing here is heroic. That is the point.

Governance

"Success" Means It Ran: The Trust Contract Around a ShEx Conversion

There is a sentence in our own transform documentation that we treat as a design constraint rather than a caveat: **a successful response does not mean nothing changed — it means it ran.**

Ecosystem

Two Questions That Sound Alike: Where ShEx Sits, and Why We Take No Side

"What does this term mean?" and "what must a conforming record contain?" sound like one question. They are two, answered by different artifacts, and confusing them is why so many schema discussions go in circles.

Agents

Ask Where the Answer Came From: ShEx as an Agent's Source of Truth

Ask an AI agent what values the `status` field can hold, and it will answer. The interesting question is not whether the answer is right. It is where the answer came from.

Quickstart

ShEx in Ten Lines: Your First CoreModels Transform

The shortest useful thing you can do with CoreModels and ShEx takes one HTTP call, writes nothing to your project, and hands back three things: the converted schema, a replayable plan, and an honest ledger of everything the conversion could not carry across. This walkthrough runs that call twice — once into JSON Schema, once into Postgres DDL — and shows you how to read all three parts of the answer.

API

The ShEx HTTP Surface: Import, Export, Map, and Replay

Five HTTP endpoints carry ShEx through CoreModels, and they are the same five that carry every other schema format we support — nothing about ShEx is a special case on the wire. What changes is one string: the format key `shex`. This article is the contract reference for that surface: exact routes, request and response bodies, roles, options, and the honest statement of what each direction can and cannot do.

MCP

Agent-Driven ShEx Conversion with the transform_schema MCP Tool

"The ontology team published ShEx shapes for the product catalog. Give me the JSON Schema our validation service needs, and tell me exactly what didn't survive the trip."

Automation

ShEx in the Pipeline: Deterministic Transforms, Replayable Plans, Batch Conversion

A schema conversion you cannot reproduce is a liability with a timestamp on it. If your ShEx shapes are converted to JSON Schema by hand, or by a script whose behavior depends on who runs it and when, then the day the outputs disagree you have no way to say *which* conversion was right. We built the CoreModels transform surface so that conversion can live in a pipeline like any other build step: deterministic outputs, a reviewable plan artifact you can commit next to your shapes, and a change report you can gate a build on. This article shows the working patterns for ShEx (format key `shex`).

Deep dive

Inside the ShEx Coder: The IR Map, the Extras Ledger, and What Round-Trips

Most schema formats name things locally: a SQL column is `full_name`, an Avro field is `full_name`, and any connection to the wider world has to be bolted on with annotations. ShEx arrives different. Its predicates and shape names are IRIs — `schema:name` *is* `https://schema.org/name` — which means a ShEx document carries its cross-standard identity in its bones. Our ShEx coder in CoreModels, by ARAMAI, is built around that fact, and this article is the full technical account of it: exactly what maps into our intermediate representation (IR), what rides in the preserved-extras ledger, every lossiness record the coder can emit, and precisely what survives a round trip.