[jdsika]

Mirror of linkml#4169, same head. Review there; this PR tracks the fork stack.

Proposed upstream description (2026-10-30), not yet applied to linkml#4169; it is copied there after review.

Merge order of this series: linkml#3716 → linkml#4168 → linkml#3993 → linkml#4144 → linkml#4171 → linkml#3989 → linkml#3990 → linkml#4156 → linkml#4157 → linkml#4158 → linkml#4028 → linkml#4169 → linkml#4170 → linkml#3446. A stack is rebased when its base lands.

Stacked on linkml#4028, which GitHub shows too; this PR's own diff is #30.

Read first: shaclgen.py (159) and jsonschemagen.py (66); 225 lines of source; the rest is tests, snapshots and docs.

Summary

A slot's range_expression constrains each of its values. gen-shacl and gen-json-schema now read it the same way, as linkml#4028 reads class-level expressions: a value must satisfy the expression as an instance of the range class satisfies a class-level expression.

Document:
  slot_usage:
    license:
      range_expression:
        none_of:
          - slot_conditions: {category: {equals_string: retracted}}

license	main: SHACL	main: JSON Schema	this PR: both
{}	valid	invalid	valid
{category: retracted}	valid	invalid	invalid
{category: draft}	valid	valid	valid

• gen-shacl ignored range_expression. It now emits an sh:node next to the range's sh:class (SHACL §4.7.1), on slots, on class alternatives of any_of, and in slot conditions, where the expression takes the form of the condition.
• gen-json-schema read it with the two-valued builder of rules (since Implementing range_expression in jsonschemagen linkml/linkml#2860), which ignores cardinalities and a condition's range, reads none_of and exactly_one_of two-valued, and resolves slots globally. It now uses feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema linkml/linkml#4028's class-expression builder. This changes the generated schema for existing range_expression users, as the table shows.
• gen-json-schema, broken on main: for a slot inlined as a dict, the slot's own value constraints applied to the dict rather than to each value, so valid data was rejected. Fixed here, because the contract above depends on it.

Decisions

• An expression SHACL can't express is skipped with one warning naming the slot, the reason and the class shapes, as feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema linkml/linkml#4028 does.
• equals_expression is not translated; neither generator enforces it on slots. gen-shacl therefore logs one warning for the metamodel's own slot_group.
• is_a combinations of types and enums are translated. A slot condition on such a value has no slots to constrain; both generators accept the value.

Other generators

• gen-owl has emitted open-world restrictions for range_expression since Implementing range_expression in jsonschemagen linkml/linkml#2860; unchanged.
• A value that is a reference: SHACL checks the referenced node's description in the data graph, JSON Schema sees only the identifier.
• ShEx, Python, Pydantic and SQL don't support range_expression; unchanged.

How was this tested?

• test_range_expression.py (113 cases, 2 strict xfails) validates the same instance with both generated artifacts, the RDF loaded through the generated JSON-LD context, plus SHACL-only cases.
• The compliance test test_range_expression_nesting now expects SHACL to implement nested range expressions.
• Rebased with feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema linkml/linkml#4028 onto main ae3df7a45 (2026-10-30), no conflict: tests/linkml 12,768 passed locally; CI on the head.

Areas of uncertainty

• is_a: <type> / is_a: <enum>: the metamodel narrows is_a of an anonymous_class_expression to class_definition, while the range_expression comment envisions combining two enums, and discussion #2791 calls an expression over named ranges desirable. The compliance suite (test_range_expression_booleans, is_a: integer) and gen-json-schema already read it that way; this PR follows them. Should the metamodel widen the range?
• Compact dict forms {id: value} and {id: null} escape the expression in JSON Schema, while SHACL rejects the resources they denote. Recorded as a strict xfail and in the docs.

Refs linkml#1776 (cmungall: "Include range_expression in jsonschemagen").

Checklist

• My code follows the contributor guidelines
• I have added tests that prove my fix/feature works
• Existing tests pass locally with my changes

AI Assistance

If you used AI tools while preparing this PR, you are still the author and responsible for understanding, verifying, and defending your submission. Please engage with reviewers personally rather than through your agent during feedback and revisions. See our AI Covenant for details.

Fork review (kept from the earlier mirror description)

2026-10-23, third push (corrected): re-stacked on the reviewed #29 (e6a40da1c), whose is_a membership rule this PR's _class_expression_shape now combines with its own type-and-enum branch: a class member goes through membership, a type or enum member gives its value constraint, and a value that is no class instance keeps sh:class / the structural $ref. The first re-stack (19b8129e3) made the compliance case test_range_expression_booleans fail, because a linkml:Any value class was read as able to be no class; #29 now leaves linkml:Any undetermined. test_shaclgen.py + test_jsonschemagen.py + test_boolean_slot_compliance.py + test_validation_context.py + test_range_expression.py: 4135 passed, 631 skipped, 2 xfailed.

2026-10-23, second push (adversarial review): rebased onto the rebased #29 (78870fa95), which now carries the dict-inlining fix of its class-expression builder that this PR had bundled (a condition on a slot inlined as a dict demanded an array and rejected valid data); the fix of the slot's own value constraints stays here, where range_expression is the only constraint that shows it. Review changes: the metamodel facts on is_a under Decisions, the compact dict forms recorded under Limitations with a strict xfail, the dict test reduced to its range_expression case. test_range_expression.py: 113 passed, 2 xfailed; test_shaclgen.py + test_jsonschemagen.py + test_boolean_slot_compliance.py + test_validation_context.py: 3977 passed, 663 skipped, 261 subtests passed.

2026-10-23: rebased onto the rebased #29. Conflicts with linkml#3485 (34b78f497): the any_of branch sh:pattern propagation now goes through this PR's branch_pv, and the slot-level sh:pattern block sits next to the range_expression block. No behaviour change.

2026-10-30: rebased with #29 onto upstream main (ae3df7a45); no conflict, no code change. tests/linkml: 12,768 passed.

Stacked on #29 (upstream linkml#4028), whose three-valued reading of class-level expressions it reuses.

Change

A slot's range_expression constrains each of its values. Both generators now read it the same way: a value must satisfy the expression as an instance of the range class satisfies a class-level expression.

Document:
  slot_usage:
    license:
      range_expression:
        none_of:
          - slot_conditions: {category: {equals_string: retracted}}

license	before: SHACL	before: JSON Schema	now: both
{}	valid	invalid	valid
{category: retracted}	valid	invalid	invalid
{category: draft}	valid	valid	valid

• gen-shacl ignored range_expression. It now emits an sh:node next to the range's sh:class (SHACL §4.7.1). This applies on slots, on class alternatives of any_of, and in slot conditions, where the expression takes the form of the condition: its "definitely true" form under sh:not.
• gen-json-schema read it with the two-valued builder used by rules, since Implementing range_expression in jsonschemagen linkml/linkml#2860 (2026-03). That builder ignores cardinalities and a condition's range, reads none_of and exactly_one_of two-valued, and resolves slots globally, missing the value class's slot_usage and aliases. It now uses feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema #29's class-expression builder. This changes the generated schema for every range_expression in use; the table shows the effect.
• gen-json-schema, already broken on main: for a slot inlined as a dict, the slot's own value constraints applied to the dict rather than to each value, so valid data was rejected. range_expression is the only value constraint a class-valued slot carries, so nothing else showed it. Fixed here, because the contract above depends on it. The matching defect of feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema #29's class-expression builder, which demanded an array for such a slot, moved to feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema #29.

Decisions

• Untranslatable input: an expression SHACL can't express is skipped with one warning naming the slot, the reason and the class shapes, as feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema #29 does for class-level expressions. An earlier version raised instead, which contradicted that policy.
• equals_expression: not translated. An earlier version translated constant equals_expression in SHACL conditions only. Neither generator enforces it on slots, so that would have introduced a second inconsistency. It is a separate feature. (The metamodel's own slot_group uses it, so gen-shacl now logs one warning for meta.yaml.)
• Non-class ranges: is_a combinations of types and enums are translated; the metamodel describes range_expression as "combining existing ranges", e.g. two enums. A slot condition on such a value has no slots to constrain: SHACL skips it with a warning, and JSON Schema's properties are vacuous on a scalar, so both accept the value.
• is_a: <type> / is_a: <enum>: the metamodel narrows is_a of an anonymous_class_expression to class_definition ("A class that any instance satisfying this expression must also be an instance of", slot_usage in meta.yaml), while its range_expression comment envisions combining two enums, and cmungall writes in discussion #2791 that the metamodel "arguably ... should allow" an expression over named ranges. The compliance suite (test_range_expression_booleans, is_a: integer) and gen-json-schema already read it that way, so both generators keep doing so; the metamodel gap is not resolved here.
• Dropped imports_closure() call: no case needed it; the imported-slot test passes without it.

Other generators

• gen-owl: transform_class_expression has emitted open-world restrictions for range_expression since Implementing range_expression in jsonschemagen linkml/linkml#2860; unchanged.
• References: SHACL checks the referenced node's description in the data graph, while JSON Schema sees only the identifier. This is a limit of the format.
• ShEx, Python, Pydantic, SQL: no range_expression support; unchanged.

Limitations

• Compact dict forms in JSON Schema: the forms {id: value} and {id: null} of a slot inlined as a dict are not constrained by the expression; SHACL rejects the resources they denote. Recorded by test_range_expression_on_compact_dict_forms (strict xfail) and in the generator docs.

Validation

• test_range_expression.py: 113 cases plus the 2 xfails. They validate the same instance with both generated artifacts (RDF through the generated JSON-LD context), plus SHACL-only cases; 32 failed on the previous head of this PR and 71 on feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema #29.
• Out-of-tree check during development: 960 random schemas and 26,654 instances (slots, lists, any_of alternatives, class-level conditions). gen-shacl, gen-json-schema and an independent three-valued model agreed on all of them; the previous head had 3,796 disagreements. That harness is not part of this PR.
• Mutation: 22 mutants of the new code; 21 killed. The survivor (condition range versus slot range in JSON Schema) is equivalent there; its SHACL counterpart is killed.
• Sweep: across 387 schemas in the repository, SHACL and JSON Schema output is unchanged, with identical errors. The one new warning is for the metamodel's own slot_group, which uses equals_expression.
• Compliance: test_range_expression_nesting now expects SHACL to implement nested range expressions (it fails on feat(generators): translate class-level boolean expressions alike to SHACL and JSON Schema #29).
• CI: see the checks on the current head.

Found, not addressed here (they predate this PR):

• gen-jsonld-context maps an aliased slot to the alias IRI, while gen-shacl and gen-owl use the slot IRI.
• SchemaLoader, and so gen-jsonld-context, crashes on value_presence inside a slot_usage range_expression.