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

Then you walk into the data platform and it vanishes. The formats there are JSON Schema, Avro, SQL DDL, data contracts — closed-world, validation-first, locally named. The one semantic format already deployed across the estate has no seat at the table where schemas are actually run.

That gap is the reason JSON-LD deserves a considered place in a schema toolchain, and the reason the shape of that place matters.

Two continents, one bridge

Draw the landscape and you get two land masses. On one side, contract formats built to validate payloads, generate code and reject what does not conform. On the other, the RDF family — OWL, ShEx, Turtle — built to describe knowledge with globally unique identifiers, where statements accumulate and completeness is never assumed.

JSON-LD is the bridge with traffic in both directions, and it holds that position because of a single design decision: it is a W3C standard for expressing RDF in ordinary JSON. A developer reads it in an editor without learning a new syntax; an RDF tool consumes it without a converter. That dual citizenship is exactly why it is worth treating as infrastructure rather than as a publishing curiosity.

One of fourteen spokes on one hub

CoreModels speaks fourteen schema format keys through a single transform surface, and jsonld is one of them, supported in both directions. Its close relatives in that set are owl and shex, which share the property that identifiers are IRIs rather than local strings. Across the water sit jsonschema, avro, protobuf, sql and the contract formats; linkml stands with a foot on each shore, YAML-native but URI-aware. A few keys are deliberately one-way — a MACH ODM entity document decodes only, because it is authored documentation rather than a generated artifact, and the Synapse profile encodes only, because its output is plain draft-07 JSON Schema you re-import as jsonschema.

The architecture matters more than the count. Every format converges on one neutral intermediate representation: a hub, not a web of pairwise converters. A JSON-LD vocabulary decodes into the same Types, Elements and Taxonomies a SQL schema or an Avro record decodes into, and from there it can be encoded into any of the others. Nobody wrote a JSON-LD-to-Avro converter. Both formats learned to speak to the hub, and the connection came free — which is also why no format in the set is privileged, including any of ours.

The conventions our coder reads and writes are the ecosystem's own, not a house dialect: rdfs:Class and rdf:Property nodes in an @graph, domains through schema:domainIncludes, ranges through schema:rangeIncludes, inheritance through rdfs:subClassOf, controlled lists as classes under schema:Enumeration, XSD datatypes for scalar ranges, prefixes declared in @context. The rdf, rdfs, xsd and schema.org prefixes are known out of the box. These are the publishing conventions schema.org itself uses, so real vocabularies work as published — no proprietary profile, no preprocessing step, no "supported subset" document longer than the spec.

Identity is the composition layer

What earns JSON-LD a particular seat among the fourteen is what it carries across the bridge: identity.

Every node's @id is an IRI, and on import each one is lifted into a mapsTo annotation — a machine-readable statement that this governed element is https://schema.org/name, not merely something labeled "name." That annotation is the common carrier the rest of the stack composes with, which is where the format stops being a niche interest.

Our ontology tooling binds terms from the public EMBL-EBI Ontology Lookup Service onto governed nodes through the same mapsTo mechanism, writing the chosen term's IRI under a standard of the form ols:<ontology>. Our JSON Schema encoder surfaces mapsTo as an x-maps-to annotation — and a test proves that a schema.org URI imported from JSON-LD survives translation into JSON Schema intact. SQL export brings the same identity back as a column comment. ShEx and OWL are IRI-native and need no translation at all. Export a governed model to JSON-LD and the encoder reverses known-namespace URIs back into compact prefixed names, emitting a minimal @context containing only the prefixes the document actually uses.

The practical consequence reaches teams who never touch RDF: a warehouse column can be traced to a published vocabulary term because a document was imported once and its IRIs were never dropped on the floor. JSON-LD is how semantic identity enters and leaves the system, even in shops whose daily formats are SQL and Avro.

Why neutrality is the point, not the marketing

There is a familiar failure mode in this corner of the industry. A tool embraces an open standard, then quietly becomes the only place where standard-shaped data is usable. The vocabulary goes in as JSON-LD and comes out as a proprietary export; three years later the linked-data strategy is a vendor dependency wearing a W3C sticker.

We designed against that, and the guarantees are checkable rather than rhetorical.

The exit door is open, and it is tested: decode, encode, decode again is structurally stable, and the encoded result is standard JSON-LD in the same publishing conventions the coder reads. We preserve what we do not model — context prefixes, original range identifiers, full member IRIs — so a document's character is not sanded down to whatever subset we happen to interpret. And we declare what does not fit instead of hiding it: constructs a target format cannot hold are reported in a typed, path-carrying lossiness ledger on every response, rather than tucked into non-standard extensions only our tooling can read.

We implement these standards. We do not own them and we do not fork them. The vocabulary stays yours, in its own conventions, with its own identifiers — and CoreModels earns its place by being the one governed point where both continents' descriptions of your world provably agree.

For the full list of formats and conversion options, see the transform section of the CoreModels docs.