Re: Sharing some real-world use of JSON-LD

Hey Pierre-Antoine

Jargon doesn’t currently generate JSON-LD frames, but it has been designed
to bridge gaps between the semantic and everyday developer worlds, so
generating framing is something we could support if needed.

Jargon takes a developer-first approach by modelling and fixing the
intended data structure up front using domain models. This imposes some
concrete structure on semantic vocabularies and helps ensure they can be
easily taken up and used by development teams — a very similar conceptual
outcome to framing.

If framing is specifically useful to you, I’m happy to compare notes or
explore how it might look in practice, especially if it helps bring
vocabulary authors, semantics, and everyday development teams closer
together, which is what we’ve built Jargon to do.

Thanks again for taking a look at Jargon.

Al


On Thu, 15 Jan 2026, 5:57 pm Pierre-Antoine Champin, <pierre-antoine@w3.org>
wrote:

> Hi Alastair,
>
> thanks for this, I will definitely try out Jargon.
>
> Question: in addition to JSON Schemas and JSON-LD contexts, do you also
> generate JSON-LD frame?
>
>   pa
> On 07/10/2025 04:10, Alastair Parker wrote:
>
> Hello all,
>
> Benjamin suggested I introduce myself. I’m Al, founder of Jargon, a
> modelling tool that we use to generate JSON Schema, JSON-LD contexts, and
> related artefacts from composable domain models.
>
> Here are two examples of how we’re using JSON-LD in practice:
>
> United Nations Transparency Protocol (UNTP):
> While I can’t speak on behalf of the UNTP team, I can share that the team
> use Jargon to model trade and supply-chain domains - a mix of UN-specific
> properties and references to established vocabularies like schema.org.
> From these models, the team generate both JSON Schema and JSON-LD contexts,
> and Jargon ensures they work together: the schema enforces mechanical @type
> properties that the context file then relies on for expansion. Jargon
> follows Domain-Driven Design, and those principles flow through to the
> @context file - with entities (things with business identity) represented
> as top-level named items that resolve to @types, and value objects (things
> without business identity) declared in nested @context entries beneath
> their owning entities. The goal is to let ordinary web developers keep
> working with JSON and their existing tooling, while still participating in
> a semantic ecosystem - but keeping their JSON feeling familiar to how it’s
> normally structured. In practice, this means things like correct @type
> values “just happen” when they generate code from the schemas - developers
> don’t even need to be aware they’re working with JSON-LD unless they choose
> to.
>
> Enterprise data provenance:
> We have enterprise customers who aren’t interested in JSON-LD or semantics
> at all, but care deeply about identifying data provenance in their JSON.
> Jargon uses Domain-Driven Design to model data that draws from multiple
> domains into developer artefacts like JSON Schema that tend to be
> monolithic, without borders resembling the input domains. As a result,
> similarly named concepts aren’t easily distinguishable in the JSON alone -
> for example, “customer” in billing vs. “customer” in support lose their
> provenance once serialised. By expanding into JSON-LD, each usage is
> grounded with a unique identifier, allowing teams to extract the provenance
> back out again. Teams rarely care what the IRIs resolve to - if anything -
> and tend only to care that they are unique enough to namespace them. Some
> teams then consume the expanded JSON-LD directly, while others simply check
> provenance in the expanded graph before discarding it and processing the
> unexpanded JSON.
>
> For us - and most of our clients, who come from more JSON, API, and
> object-oriented exchange backgrounds - JSON-LD has proven to be the
> simplest and most effective way to carry “just enough” semantics alongside
> JSON for consumers who want it, even if that’s where semantics ends, and
> never touches RDF, triples, or graphs. This also joins up well with how
> these customers are designing and governing the individual domains in
> Jargon - giving them strong alignment between design and implementation
> that smooths over many bumps in shared understanding. We’ve also found that
> these approaches haven’t ruffled too many feathers among JSON purists, with
> the artefacts working seamlessly in typical JSON pipelines.
>
> Al
>
>