Re: joint JSONLD-Ontology-SHACL validation

Hello

I wanted to share our experience in SHACL Play to generate JSON-LD contexts
from SHACL itself [1] (as well generating the corresponding JSON schema
[2]). The JSON-LD context generation algorithm is at [3].
The point being : in RDF environments, why use yet another polyglot
modeling layer when you can do it directly from SHACL (when you have your
SHACL definitions already written) ? (we consider SHACL as the source of
truth for the model).

Cheers
Thomas

[1] : https://shacl-play.sparna.fr/play/context#algorithm
[2] : https://shacl-play.sparna.fr/play/jsonschema#algorithm
[3] :
https://github.com/sparna-git/shacl-play/blob/master/shacl-jsonschema/src/main/java/fr/sparna/rdf/shacl/jsonld/JsonLdContextGenerator.java



Le mar. 27 janv. 2026 à 08:57, Vladimir Alexiev <
vladimir.alexiev@graphwise.ai> a écrit :

> A discussion "Sharing some real-world use of JSON-LD" turned towards
> discussion of errors in JSON-LD contexts.
> Here are two examples:
>
>    - Collapsing of Class vs Property in Context: eg this in UNTP (DPPs
>    etc)
>    "partyAlsoKnownAs": {"@id": "untp-core:Party"...}
>    This perhaps comes from the inability of JSONLD to infer a @type
>    (rdfs:range reasoning)
>    - Publishing an ontology instead of context (by EKGF DPROD of all
>    people!):
>    https://github.com/EKGF/dprod/issues/93
>
> Then Alastair Parker of jargon.sh wrote:
> > 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.
>
> I think this is a very important question to ease and increase
> the adoption of JSONLD and ultimately semantic technologies.
> I think the only way to do this is by cross-checking of the Context
> against Ontology definition and/or SHACL.
> So it strongly relates to 2 things:
>
>    - Polyglot modeling https://github.com/json-ld/yaml-ld/issues/19,
>    because the best way to produce coordinated Context+Ontology is to produce
>    them from a unified model.
>    LinkML is perhaps the leading framework, Jargon is another great
>    example, and OO-LD is one of the few that can attach target @type
>    - DX PROF because it offers a way to package coordinated tech
>    artefacts:
>    context, ontology and shapes (and examples, and JSON schema etc etc)
>    - Perhaps SHACL Profiling
>
> Nick, should I post this as a SHACL Profiling usecase?
> I know I've been letting the SHACL WG down for lack of time... :-(
>
> --
>
> Vladimir Alexiev, PhD, PMP
> Chief Data Architect
> Ontotext, doing business as Graphwise
>
>
> Websites www. <https://www.semantic-web.com/>graphwise.ai,
> www.ontotext.com, www.semantic-web.com
>
> Publications/CV <https://rawgit2.com/VladimirAlexiev/my/master/index.html>
> , LinkedIn <https://www.linkedin.com/in/valexiev>, GitHub
> <https://github.com/VladimirAlexiev/>, Scholar
> <https://scholar.google.bg/citations?user=r4TvZdYAAAAJ&hl=en>, Calendar
> <https://www.google.com/calendar/embed?src=vladimir.alexiev@ontotext.com>
> , +359 888 568 132 <359888568132>
>
>

-- 

*Thomas Francart* -* SPARN**A*
linked *data* | domain *ontologies* | *knowledge* graphs
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97