Connect JSON-LD
Make the vocabulary you already trust executable downstream.
How CoreModels works with JSON-LD
JSON-LD is a description of meaning: `@graph` classes and properties, `@context` expansions, stable IRIs. Pipelines need schemas they can validate and tables they can load. The usual bridge is a person with a deadline.
CoreModels decodes JSON-LD into the neutral model and encodes out to the formats those pipelines actually run. The lossiness ledger shows which constraints traveled and which could not. Re-import the vocabulary and audit generated artifacts against it so the next curator edit is not stranded in a file nothing reads.
Use this when the vocabulary is already the best description of the business — and you are tired of every system keeping its own stale copy.
Recipes
No recipes yet for JSON-LD. 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.
You Already Have the Vocabulary. Why Can't Anything Use It?
Somewhere in most organizations that take meaning seriously, there is one document nobody argues with. It might be a partner's published vocabulary, a domain model built by a standards-literate team, or a profile of schema.org. It is written in JSON-LD: classes and properties in an `@graph`, each carrying a globally unique identifier, with a `@context` declaring exactly which namespace every short name expands into. It is often the most carefully reasoned description of the business anyone in the building owns.
OutcomesAfter the Import: The Requests That Stop Being Projects
The clearest sign that a vocabulary has been properly adopted is not a diagram. It is a category of request that stops requiring a meeting.
GovernanceWho Is Allowed to Change What Your Model Means?
Every organization has an answer, and in most of them the honest one is: whoever ran the last import. A tool ingested a document, wrote what it found, and a governed concept shifted meaning because a parser made a decision at three in the morning.
EcosystemJSON-LD Is Everywhere Except in Your Pipeline
You have already shipped JSON-LD, whether or not you think of it that way. It sits in the head of your marketing pages as structured data. It is how schema.org publishes its own vocabulary. It is the interchange shape for a great many knowledge graphs, research catalogs and public reference datasets, because it lets a document be plain JSON to an application developer and RDF to a triplestore at the same time.
AgentsA Field Name Is a Rumor
Give a capable model two schemas and ask it to align them. It will produce a clean mapping table in seconds: `name` to `full_name`, `status` to `state`, `created` to one of the four fields called `date`. Most rows will be right — which is what makes the output dangerous. A mapping that is mostly right ships, and the rest becomes a data-quality incident with excellent grammar.
QuickstartZero to First Transform: Running a JSON-LD Vocabulary Through CoreModels
By the end of this page you will have made exactly one HTTP call and produced two artifacts: a JSON Schema generated from an RDF vocabulary, and a lossiness ledger that states — in writing — what the conversion could not carry across. Learning to read both is the entire skill. Everything else in the CoreModels transform surface is a variation on this loop.
APIFour Verbs and a Vocabulary: The JSON-LD HTTP Surface, With Real Bodies
Everything you can do with an RDF vocabulary on the CoreModels HTTP API fits in four routes. One writes a vocabulary into a governed project, one publishes a project back out as a vocabulary, one converts statelessly through the mapping engine, and one replays a stored conversion. This article walks all four with request and response bodies we actually ran, then states the direction limits plainly — including the one that has no ledger entry to warn you about it.
MCPThree Questions an Agent Must Answer After Converting a Schema
When an agent converts a vocabulary into something else, it should be able to answer three questions afterwards: what did it produce, what did it lose, and can it do that again identically? Most conversion tooling answers the first. The `transform_schema` tool on the CoreModels MCP server answers all three in a single call — the produced schema, an explicit lossiness ledger, and the executed plan as a replayable artifact. This article runs a JSON-LD vocabulary through it end to end, with the exact arguments and the exact response.
AutomationBoring on Purpose: JSON-LD Conversion Pipelines That Produce the Same Bytes Every Time
A generated artifact is only trustworthy if it is boring. If regenerating last week's JSON Schema from the same vocabulary reshuffles keys, renames anonymous constructs, or quietly drops a constraint, then the diff in your pull request is noise and nobody reads it. This article is our recipe for the opposite: JSON-LD conversions that are byte-stable, gated by a reviewed plan, and loud when meaning is lost.
Deep diveThe Coder That Never Complains: A Full Accounting of JSON-LD Fidelity in CoreModels
Here is the fact that should make you suspicious: in either direction, the CoreModels JSON-LD coder emits no lossiness records at all. Not "few" — none. Most coders in the engine keep a list of things they apologize for; this one's ledger is empty. That is either an honest structural property or a place where losses hide, so this article is the accounting: what maps to what, what rides in the extras channel, what the `@id` contract guarantees, where fidelity breaks, and what the tests pin down.