ShEx logoOutcomes

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.

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.

Tuesday, 09:40 — the shapes arrive

A partner publishes a revised ShExC document. In the old world this opened a work item with a two-week tail: read the shapes, interpret each constraint, argue about names, draft a table design, book a review, and discover halfway through that nobody is sure whether ? meant optional or missing.

Now a project admin posts the document to the schema import endpoint with the format key shex, and it lands as governed structure. Shapes become Types. Triple constraints become Elements carrying their own facts — required or optional, one value or many — because the markers were read rather than skimmed. Value sets become Taxonomies with their terms in order, a shape reference becomes a typed reference between models, and EXTENDS becomes inheritance.

Because this partner built its shapes on public vocabulary predicates, the import also delivers something nobody requested: every Type and Element arrives carrying the corresponding URI as a cross-standard mapping. That used to be a curation project with a budget and a spreadsheet. Here it is a consequence of parsing the file.

Tuesday, 11:15 — the response is read, not skimmed

The import returns a lossiness ledger, and today it has two entries. One shape declared two parents and was narrowed to a single parent — recorded, shape named. One predicate used a value constraint with no equivalent primitive and was approximated as a string — recorded, element named, the original token preserved so it re-emits unchanged on the way out.

Two entries, two decisions: the narrowed inheritance needs a modeling conversation next sprint; the approximated constraint is fine, because nothing downstream depends on it. Both are decided in the hour the file arrived, by someone holding the evidence.

Wednesday, 14:00 — three teams, three artifacts, one source

The warehouse team wants DDL, the streaming team an Avro record, the API team JSON Schema. All three are exports of the same governed project: choose a format, choose the SQL dialect where it applies — postgres, mysql, or sqlserver — and read the result. Exporting is a Viewer read, so nobody queues behind a change ticket for one.

The artifacts land shaped by their targets. Optional predicates come out of the Avro export as nullable unions; the value set comes out as an Avro enum with its symbols intact. The same value set going to Postgres comes out as a text column, and the response says so: the target has no inline enum construct, so the allowed-value constraint is not enforced, at this path.

That sentence is the upgrade. Before, the fact was learned months later by a row nobody expected. Now it arrives attached to the artifact, while the engineer still has the file open — early enough to add a check constraint, a validation step, or a note on the ticket.

Thursday, 10:30 — a governed change, made once

A reviewer approves one new element on one Type, made in the governed model through the normal review path by a person with the role to make it. Nobody edits the DDL. Nobody edits the Avro. Nobody opens the ShExC file. The change exists in one place, and every projection of it is regenerated on demand from that place.

Friday, 09:00 — the return trip is a diff

The partner asks for updated shapes. This is where the fidelity engineering pays.

When the document came in, the coder kept the prefix map, the exact predicate on every constraint, and the original xsd: datatype token on every value — the difference between a date and a date-time, a decimal and a double, preserved even where both collapse to one primitive internally. The export re-emits them, so the regenerated document reads like the one the partner sent, plus one new triple constraint. Encoding the same model twice produces the same document, not a reshuffled one.

Before, return submissions were rewritten from scratch and reviewers waded through churn — reordered prefixes, renamed shapes, a datatype silently widened — hunting for the real change. Now the diff is the change.

Friday, 15:20 — a second partner turns out to agree already

A different organization sends a model in another format that also anchors its terms in public vocabulary URIs. Historically this began an alignment exercise: line up field names, argue about email versus contactEmail, build a crosswalk sheet, watch it rot.

Instead the mapping call runs: source format in, target format out, the two models compared through the engine. It is stateless — nothing is written to any project — and it returns the produced schema, the honest loss report, and the executed plan as a replayable artifact naming what was matched and what was not. Attach the plan to the change request; replayed later against the same source, it produces the same output.

Two organizations that never coordinated a single field name discover they were already compatible, because both said what they meant in identifiers rather than prose.

What the week actually bought

Count the before: four hand-built artifacts, four private interpretations, four independent decay curves, one shape file maintained by whoever last touched it, one specialist as a single point of failure.

Count the after: one governed model, four generated projections, four ledgers describing what each target could not hold, a return path producing a reviewable diff, and a mapping plan filed with the change request. The RDF-fluent side never wrote SQL; the SQL-fluent side never wrote ShExC; neither lost the precision the other relied on.

One habit separates a team that benefits from this from a team that has merely automated document production: read the ledger every time. A successful response means the operation ran, not that nothing changed. Teams that internalize that treat generated artifacts as deliverables with known limits; teams that skip it ship files they have not understood, faster than before.

Reach this state once and ShEx stops being the difficult attachment from a partner. It becomes one more projection of a model you already govern — the one the linked-data world happens to read.

The schema import and export quickstarts at https://coremodels.example.com are enough to run the circuit against your own project.