[pfraze]

I see JSON-LD show up in a lot of standards-driven document formats and it's made sense to me in that context. For instance, in DIDs^1 the basic document shape is established by one standard but then the key material is often identified using other standards. JSON-LD makes possible to merge together the definitions from the multiple standards without too much trouble or loss of specificity.

How you actually use JSON-LD seems to vary in practice. Programmatically, the most useful thing it can do is normalize a JSON into a shape you expect without losing specificity^2. More often, however, it serves as a form of documentation for where the terms are coming from, because developers will usually try to maintain a nice shape with the JSON documents they produce.^3

The @context is hard for developers to create, however, so outside of the standards process I'm unsure it gets a lot of utility. I'm also unsure how reliably the @context values have consistent machine-readable documents produced, so the programmatic value may be limited.

^1 Which we'll assume are a good thing for the purpose of this conversation.

^2 You can do this by expanding the JSON into the very noisy RDF graph-triple form, then re-condensing it into an object with sane (unprefixed, non-URL) keynames and values using your own @context.

^3 Of course you can't RELY on people to do that, which is where the programmatic utility comes into play.