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

Hi Alastair!
Let me know how I can help with making Jargon's semantic support better.
If you want, I can post those as individual issues on a tracker, and
provide more information.

People on this list may be SHOCKED at some of the misuses I've witnessed in
the real-world.
(Given that the original intent of JSONLD is to simplify and make it
accessible to non-semtech people).

1. Even people knowledgeable about ontologies sometimes make absurd
mistakes.
Eg DPROD, which was made by EKGF (FIBO people) and endorsed as an OMG spec.
Eg see these issues
https://github.com/EKGF/dprod/issues?q=author%3Avladimiralexiev
and in particular https://github.com/EKGF/dprod/issues/93 .

2. Collapsing of Class vs Property in Context: there were a lot of such
errors in W3C CG Transparency...

"How to do automatic validation": this is a very excellent question!



On Mon, Jan 19, 2026 at 4:40 AM Alastair Parker <
alastair@dataexchangeapparatus.com> wrote:

> Hi Vladimir,
>
> I’m glad to hear you found Jargon useful, and thanks for taking the time
> to look at it through an ontology lens. Feedback from ontology
> practitioners is genuinely valuable.
>
> To answer your question directly: no, Jargon does not use Langium or any
> other external DSL framework. We have a number of UX, governance, and
> live-validation requirements that pushed us toward a bespoke and tightly
> integrated language and tooling stack.
>
> It’s entirely possible that there are issues in Jargon’s JSON-LD artefact
> generation for UNTP. While I don’t represent UNTP, I can say that JSON-LD
> has been a learning experience for everyone involved, and the approach so
> far has been intentionally iterative. We’ve been trying to land on
> something that balances ontology expectations with accessibility for
> broader developer and implementer audiences.
>
> The list of points you’ve outlined below looks like a reasonable and
> constructive set of things to examine, particularly where it would make the
> generated JSON-LD more idiomatic and approachable for ontology-focused
> communities.
>
> One thing I do think would materially help the JSON-LD ecosystem more
> broadly is better automation around detecting these kinds of issues. As a
> tool vendor, we’ve put a lot of effort into producing correct and compliant
> JSON-LD, but there is no widely adopted, machine-executable suite of design
> or compliance rules that check for many of the modelling, consistency, and
> stylistic concerns you’ve raised.
>
> By contrast, in the OpenAPI world, communities rely heavily on rule-based
> linting (for example using Spectral) to express outcome-focused design
> rules that can run in CI/CD pipelines. I’ve experimented with applying a
> similar approach to JSON-LD and currently use a small internal rule set
> within Jargon’s generation pipeline, but those rules are necessarily
> incomplete and largely derived from observed UNTP patterns rather than
> community-wide consensus.
>
> ’ll follow up with you offline on the individual issues you’ve listed here
> about UNTP and Jargon behaviour. I’m also happy to work with Jargon users
> within UNTP to address any issues that stem from how the tool is being
> applied in practice.
>
> Thanks for your constructive feedback, and for sharing your review.
>
> On Fri, 16 Jan 2026, 5:53 pm Vladimir Alexiev, <
> vladimir.alexiev@graphwise.ai> wrote:
>
>> Hi Alastair!
>> I've tried Jargon for UNTP and it's very nice. Is it made with Langium?
>>
>> But I made a review of UNTP
>> <https://docs.google.com/document/d/1R3yqaYCO3JTpWsIckSzbumzyQgwRvd5X4Ewg-9Ax4yU/edit?tab=t.0>, and
>> I think some of the bugs in the ontologies are due to Jargon, and can be
>> fixed systematically by improvements to Jargon.
>> Could you please weigh in on that, or work with UNTP on identifying which
>> issues are due to Jargon?
>> The review links to individual issues at
>> https://opensource.unicc.org/un/unece/uncefact/spec-untp, or if you
>> prefer you can just comment in the doc and I'll reflect in the issues.
>> Here are some guessed issues due to Jargon:
>>
>>    - #517
>>    <https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/517>
>>    Issue: When a term is reused from "core" to another ontology module,
>>    it is recast in the target namespace, resulting in duplicated terms
>>    (same localname, different namespaces).
>>    - #516
>>    <https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/516>
>>    Add Turtle variant of ontologies.
>>    - I don't know whether Jargon is intended to provide resolution. If
>>    so: amend semantic resolution by adding content negotiation for Turtle (it
>>    already returns HTML and JSON-LD).
>>    - #518
>>    <https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/518>
>>    Issue: *don't allow* props with the same local-name to be defined
>>    discrepantly as Object vs Datatype Property, eg
>>
>>    untp-core:conformance a owl:DatatypeProperty, rdf:Property ;
>>
>>    untp-dcc:conformance a owl:ObjectProperty, rdf:Property ;
>>    - Don't allow a datatype property to point to a class. Eg here the
>>    first one should be Boolean, the second string
>>
>>    untp-dcc:conformance schema:rangeIncludes untp-core:conformance.
>>
>>    untp-dte:name        schema:rangeIncludes untp-core:name .
>>    -
>>
>>    #519
>>    <https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/519>
>>    Issue: generate owl:Ontology declaration.
>>    -
>>
>>    Generate owl:imports
>>    -
>>
>>    Use rdfs: domain/range in addition to schema: domain/rangeIncludes
>>    -
>>
>>    In the ontology context, define the type of subClassOf:
>>
>>    "rdfs:subClassOf" : {"@type" : "@id"}
>>
>>    Else you get invalid axioms like this: untp-dte:ObjectEvent
>>    rdfs:subClassOf "untp-dte:Event" .
>>    - Collapsing of Class vs Property in Context: eg this is wrong
>>    "partyAlsoKnownAs": {"@id": "untp-core:Party"...}
>>    - On the Artifacts page, can you rename these two links to *Ontology
>>    as JSON-LD *and *JSON-LD Context*?
>>    [image: image.png]
>>
>>
>> Jargon is an example of what I call polyglot tools, see a list in Issue
>> #19 · json-ld/yaml-ld - Polyglot Modeling
>> <https://github.com/json-ld/yaml-ld/issues/19>
>> Hi Roberto! Your efforts are listed at the polyglot list (Search for
>> @ioggstream), I've now added the 2 links that you shared.
>>
>> Cheers!
>>
>