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

On 16/01/2026 05:23, Alastair Parker wrote:
> 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.

My reasoning is as follows:

provdining a JSON-LD context allows people to consume the data as an RDF 
graph; once the data is converted into triple and processed in "RDF 
land", these people may want send the resulting data back as JSON(-LD) 
complying with the corresponding JSON-Schema. This is where a frame 
would be useful.

   best

>
> 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 <http://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
>