DPROD Contracts: reject per-policy odrl:conflict override (2.4)

[jgeluk]

Track: DPROD 1.1 data-contracts post-merge follow-up.

Plan item 2.4 of dprod-contracts/docs/changes-plan.md (source: Matthias email 19d08a1d item #13). The DPROD spec fixes the conflict policy to "Prohibition > Permission". A per-policy odrl:conflict declaration would silently change that semantics, so it should be rejected by SHACL.

Steps:

1. Add dprod-shapes:RejectPolicyConflictShape (after the existing Reject* block in dprod-contracts-shapes.ttl) with sh:targetSubjectOf odrl:conflict and:
   sh:property [ sh:path odrl:conflict ; sh:maxCount 0 ; sh:severity sh:Violation ; sh:message "DPROD contracts fix conflict resolution to Prohibition > Permission; per-policy odrl:conflict is not allowed." ]

Verify: a test policy with odrl:conflict odrl:prohibit triggers a violation; existing examples without it still pass.

Note: follows the same declarative sh:targetSubjectOf pattern adopted for the other Reject* shapes in item 2.2.

[jgeluk]

(These are verbal comments of Matthias):

In ODRL there is a term called "Conflict", it should give a "hint" to the ODRL engine whether the conflict resolution principle should be "does the permission win" or "does the prohibition win"? The policy engine should decide that based on the conflict resolution.

If you create a data contract that contradicts itself then you should not have it?

You want fail fast, no conflict resolution.

[jgeluk]

Investigation result: this issue should not be implemented as currently written. Matthias's comment changes the intended decision from "prohibition wins" to "a contradictory contract is invalid."

The repository currently contradicts that decision at several levels:

• dprod-contracts/dprod-contracts-prof.ttl declares odrl:conflict odrl:prohibit.
• dprod-contracts/docs/formal-semantics.md explicitly gives prohibitions priority.
• dprod-contracts/docs/specification.md repeats the fixed "Prohibition > Permission" model.
• The current SHACL graph accepts both:
  • a permission and prohibition for the same action and asset;
  • a per-policy odrl:conflict odrl:perm override.

There is also a modelling error: odrl:conflict has domain odrl:Policy, but DPROD attaches it to a prof:Profile. The W3C model already defaults an omitted conflict strategy to odrl:invalid, meaning conflicting rules void the policy: ODRL Information Model §2.10, ODRL vocabulary.

The root cause is that conflict was treated as an evaluator precedence rule rather than a policy well-formedness invariant.

Recommended revised acceptance criteria:

1. Reject every policy-level odrl:conflict assertion.
2. Remove odrl:conflict odrl:prohibit from the DPROD profile.
3. Reject permission/prohibition overlap during validation.
4. Make conflict-free policies a precondition of evaluation; hard-error if invalid input bypasses validation.
5. Remove the "Prohibition > Permission" algorithm, documentation, and monotonicity theorem.
6. Add regression tests first for direct conflicts, action-hierarchy conflicts, per-policy overrides, and a non-conflicting policy that remains valid.

One scope decision remains: whether conflict-freedom applies only within each contract or across every policy set supplied to Eval. Matthias's "no conflict resolution" implies the latter; otherwise the evaluator still needs a precedence rule.

[matthiasautrata]

Almost agree. At this stage, simplicity and clarity should win. So: Take conflict out of the profile/prohibit it in SHACL. Otherwise, I would still argue for prohibit wins over permit if it activates. Alternatively: Conflict = error. I am not sure how we would detect conflicts at policy authoring time. That would require much more machinery and semantic specs which we don't have in ODRL currently.