Re: Graph Merging Algorithms and JSON-LD Schemas

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> 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>
> *Sent:* Friday, February 27, 2026 10:20 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
>
> 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>
> 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(...)
> {
>     ...
> }
>
>