JSON-LD Schemas (was: Re: Graph Merging Algorithms and JSON-LD Schemas)

Hey Adam,

I'm a bit lost by the phrase "JSON-LD Schemas". It seems you're looking for terms to use in your context file-which points toward ontologies, etc. SHACL has also come up in the conversation-which is a constraints method...so, sort of a "schema".

Putting the values of two JSON-LD documents into a single graph (and then possibly spitting them back out as a new JSON-LD document) is very possible, and one of the major reasons one might pick JSON-LD over "just JSON". However, JSON-LD itself doesn't provide "schemata"-which typically focus on "constraint" and often at ingest (ala JSON Schema).

What JSON-LD does provide is term mapping, so one can declare that when term "whatever" is used in their JSON it is specifically "https://example.org/#whatever". That "unequivocable meaning" plus the underlying graph model makes merging JSON-LD documents relatively trivial.

Anyhow. Were you looking for something beyond specific context terms?

Cheers,
Benjamin

--
https://bigbluehat.com/
https://linkedin.com/in/benjaminyoung



________________________________
From: Rob Atkinson <ratkinson@ogc.org>
Sent: Saturday, February 28, 2026 5:48 PM
To: Roman Evstifeev <someuniquename@gmail.com>; Adam Sobieski <adamsobieski@hotmail.com>
Cc: public-json-ld@w3.org <public-json-ld@w3.org>
Subject: Re: Graph Merging Algorithms and JSON-LD Schemas

The Profiles Vocabulary has just such a construct:

https://www.w3.org/TR/dx-prof/

https://www.w3.org/TR/dx-prof/#Class:ResourceDescriptor

It uses dct:conformsTo but allows role and encoding format details.

The PROF roles register should be extensible like the IANA register to support whatever nuances are required.

Note this is in scope to bring into REC status as part of the DX PROF and SHACL shapes WG activities.

Dash: has a lot of other stuff in it and it not on a standards track.
Rdfs:seeAlso is semantically weak and cannot be annotated regarding purpose.

Rob Atkinson
Senior Research Engineer  | Open Geospatial Consortium (OGC)
Mobile: +61 419 202973
ratkinson@ogc.org<mailto:ratkinson@ogc.org> | ogc.org<http://ogc.org/> | @opengeospatial


[https://ci3.googleusercontent.com/meips/ADKq_NYvdzG5CnR-DX7WeJyPCnJuhbJ_G7lH1yVbaql72titKCiG-t4HQ92DiCCRM2jU42bDT20Ge7sBVIodm8VpmVBlrnTKCg=s0-d-e1-ft#https://portal.ogc.org/files/?artifact_id=99287]

________________________________
From: Roman Evstifeev <someuniquename@gmail.com>
Sent: Saturday, February 28, 2026 5:08 PM
To: Adam Sobieski <adamsobieski@hotmail.com>
Cc: public-json-ld@w3.org <public-json-ld@w3.org>
Subject: Re: Graph Merging Algorithms and JSON-LD Schemas

You don't often get email from someuniquename@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Perhaps dct:conformsTo can fit as well:

dct:conformsTo
(derived from DCMI Metadata Terms) is a Dublin Core metadata property used to link a resource (such as a dataset distribution) to a specific standard, specification, schema, or profile it adheres to. It is essential for machine-readability in data catalogs, particularly within the DCAT (Data Catalog Vocabulary) framework.
Key details regarding dct:conformsTo:

    Purpose: It identifies the model, schema, ontology, or profile that a dataset or its distribution follows.

On Sat, Feb 28, 2026, 11:06 Roman Evstifeev <someuniquename@gmail.com<mailto:someuniquename@gmail.com>> wrote:
With the help of google, I got few suggestions:

If you have a machine readable vocabulary with your rdfs or owl classes, then
to link an rdfs:Class (subject) to a sh:NodeShape (object), you can use properties from the DASH or SHACL vocabularies, depending on your intent:


dash:shape: This property is part of the DASH Data Shapes Vocabulary. It is specifically designed to state that a resource (such as an rdfs:Class or an individual instance) is associated with or "has" a given shape.
        Subject: rdfs:Class
        Object: sh:NodeShape
        Usage: Often used in data graphs to capture validation results or to manually map classes to specific shapes for UI generation.

sh:targetClass (Inverse): While technically used in the opposite direction (Shape
    Class), in many SHACL-based tools like TopBraid Composer, the relationship is treated as bidirectional for navigation. If you must have the class as the subject, dash:shape is the standard "well-known" choice.


rdfs:seeAlso: If you prefer a core W3C RDF Schema property, rdfs:seeAlso can link any resource to another that provides additional information. While not SHACL-specific, it is frequently used in ontologies to point to external constraint definitions.

On Sat, Feb 28, 2026, 10:34 Adam Sobieski <adamsobieski@hotmail.com<mailto:adamsobieski@hotmail.com>> wrote:
Roman,
All,

Thank you. SHACL makes sense for constraining and validating merge results.

Brainstorming about how best to refer to SHACL resources from schemas, if there isn't already a best practice or technique, perhaps, drawing inspiration from HTML's "<meta>" and "<link>" elements, schema authors could express something resembling:

"ext:metadata": [{
   "@type" : "ext:Link",
   "ext:rel": "ext2:validation",
   "ext:type": "text/turtle",
   "ext:href": "https://example.org/shacl/constraints.ttl"
}]


Best regards,
Adam


________________________________
From: Roman Evstifeev <someuniquename@gmail.com<mailto:someuniquename@gmail.com>>
Sent: Friday, February 27, 2026 10:20 PM
To: Adam Sobieski <adamsobieski@hotmail.com<mailto:adamsobieski@hotmail.com>>
Cc: public-json-ld@w3.org<mailto:public-json-ld@w3.org> <public-json-ld@w3.org<mailto:public-json-ld@w3.org>>
Subject: Re: Graph Merging Algorithms and JSON-LD Schemas

If you want automated consistency check, have a look at shacl. It lets you formally define and verify desired shape of the resulting graph after merge. For instance, the rule sh:maxCount 1 ; set on property will ensure that it can't have two different values.

On Sat, Feb 28, 2026, 01:33 Adam Sobieski <adamsobieski@hotmail.com<mailto:adamsobieski@hotmail.com>> wrote:
JSON-LD Community Group,

With respect to merging JSON-LD documents, two at a time, should JSON-LD schemas be able to express per-property rules or hints to override default merging-algorithm behaviors?

In many cases, properties each having a single value could be merged into arrays with two elements. In many cases, values and arrays could be concatenated, treating values as singleton arrays. In many cases, arrays could be simply concatenated.

For some Boolean properties, however, developers might want to be able to indicate that these properties' values could only be merged if two documents' values were identical, to avoid a property having both a "true" and "false" value in a merge result. One might want to be able to define, using JSON-LD schema, that a merging algorithm should throw an error if two distinct values were being merged for a certain property.

What do you think about being able to specify per-property rules or hints for JSON-LD graph-merging algorithms, being able to override default algorithm behavior, being able to indicate if and when to throw errors, using JSON-LD schemas?


Best regards,
Adam Sobieski

P.S.: Motivating use cases include developers being able to provide inline or URL-addressed JSON-LD data in security-related (e.g., access-control-related) attributes, annotations, and decorators on functions and methods. As envisioned, JSON-LD content could be merged together from multiple decorators' metadata, into the resultant metadata for a function or method...

@mcp_tool('foo')
@metadata(fetch('https://example.org/security/category-1.jsonld'))
@metadata(fetch('https://example.org/security/resource-use-3.jsonld'))
foo(...)
{
    ...
}