DPROD Contracts: define and fail-closed validate the supported ODRL operator set

[jgeluk]

Context

Follow-up from #198 (fixme.md items 23 and 31).

The supported ODRL operator surface is inconsistent:

• docs/policy-writers-guide.md advertises odrl:isAllOf.
• docs/formal-semantics.md omits isAllOf from both ComparisonOperator and apply.
• dprod-contracts-shapes.ttl accepts any value typed as an ODRL operator instead of enforcing the evaluator's supported set.
• Other standard ODRL operators (hasPart, isA, isPartOf) and andSequence are neither implemented nor explicitly rejected.

An accepted policy must never reach an evaluator operation whose semantics are undefined.

Decision required

Define the exact ODRL comparison and logical-constraint surface supported by DPROD Contracts. Every supported construct must have formal evaluation semantics; every unsupported construct must fail SHACL validation.

Acceptance criteria

1. Add regression tests first showing that isAllOf is currently documented but not represented by the formal evaluator, and that an unsupported operator currently passes validation.
2. Publish one normative supported-operator matrix.
3. Add formal semantics for every supported operator, including isAllOf if retained.
4. Add SHACL allow-list validation and hard-error on unsupported operators and logical operands.
5. Align the ontology, specification, writer guide, examples, and formal semantics with that matrix.
6. Existing examples continue to validate.

Unknown operators must not be treated as false, ignored, or delegated to an unspecified fallback.

[jgeluk]

Decision options

The invariant should be: every construct that passes SHACL has complete evaluator semantics. An unknown operator must be a validation error, never false, ignored, or delegated to an unspecified fallback.

Option A — closed minimal core (recommended for DPROD 1.1)

Support exactly the operators already defined by the formal evaluator:

• equality: odrl:eq, odrl:neq
• ordered comparison: odrl:lt, odrl:lteq, odrl:gt, odrl:gteq
• membership: odrl:isAnyOf, odrl:isNoneOf

Support exactly these logical forms:

• odrl:and
• odrl:or
• dprod:not

Remove odrl:isAllOf from the writer guide and reject it, odrl:hasPart, odrl:isA, odrl:isPartOf, odrl:andSequence, odrl:xone, and every unknown operator in SHACL.

This is the smallest coherent surface and can be implemented without inventing more collection, type, or sequence semantics.

Option B — expanded closed core

Retain Option A and add a specifically agreed set, most plausibly odrl:isAllOf. For every addition we must define:

• whether the left and right values are scalars, sets, or either;
• duplicate and empty-set behaviour;
• datatype compatibility;
• the exact Boolean result for each operand shape;
• SHACL validation for those operand shapes.

Other ODRL operators should be added only if their DPROD interpretation is specified at the same precision. Anything not selected still fails validation.

Option C — profile-extensible operator registry

Keep a small core, but permit extension profiles to declare additional operators together with a machine-verifiable processor capability and normative evaluation contract. A policy is valid only when its profile declares the operator and the selected evaluator advertises that capability.

This enables later extensions, but requires a capability/profile mechanism that DPROD does not currently have. Merely typing an IRI as odrl:Operator is not sufficient.

Proposed disposition

Choose Option A for DPROD 1.1. It matches the formal semantics, maximises enforceability, and leaves Option C available as a later extension when a real business requirement justifies the capability mechanism.

A decision for Option B needs the exact additional operator list; “support standard ODRL operators” is not precise enough.

[jgeluk]

Decision: retain ODRL capabilities; add no DPROD operators

This supersedes the earlier recommendation to use a reduced operator allow-list.

DPROD Contracts will support the relational operators defined by the ODRL 2.2 Common Vocabulary:

• odrl:eq, odrl:neq
• odrl:lt, odrl:lteq, odrl:gt, odrl:gteq
• odrl:hasPart, odrl:isPartOf, odrl:isA
• odrl:isAllOf, odrl:isAnyOf, odrl:isNoneOf

odrl:isAllOf is retained because it is an ODRL-defined operator, not a DPROD invention.

The logical-constraint surface will likewise use only ODRL-defined constructs:

• odrl:and
• odrl:or
• odrl:xone
• odrl:andSequence

DPROD Contracts will not define or support dprod:not in the current profile.

This is an intentional breaking change. The #237 implementation must:

1. define deterministic evaluation and operand-type semantics for every listed ODRL construct;
2. enforce the supported ODRL set in SHACL and reject every unknown operator or logical operand;
3. remove dprod:not from the ontology, SHACL, abstract syntax, formal semantics, examples, and authoring documentation;
4. make existing dprod:not usage fail validation rather than be ignored.

General logical negation may be reconsidered later only if a concrete business requirement justifies a profile extension and its interaction with unresolved operands and fail-closed evaluation is fully specified.