Re: Graph Merging Algorithms and JSON-LD Schemas

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>
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>
> 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(...)
>> {
>>     ...
>> }
>>
>>