DPROD Contracts: path-traversal sandboxing and grammar (6.2)

[jgeluk]

Track: DPROD 1.1 data-contracts post-merge follow-up from PR #156. Adalbert (Matthias Autrata) feedback.

Plan item 6.2 of `dprod-contracts/docs/changes-plan.md`. Downstream of #186 (`dprod:path` OWL typing).

DPROD evaluators that resolve `dprod:path` against a backing knowledge graph need a well-defined grammar for what paths are allowed and a sandboxing story for what they can reach. Today the path syntax is described informally (simple IRI, RDF-list sequence) and the formal-semantics doc has a `traverse()` function but no normative grammar or termination guarantees.

Concrete deliverables:

1. Normative grammar for `dprod:path` values — pin down whether SPARQL inverse / alternative / negated-property paths are supported, or whether DPROD restricts to forward-only sequence paths
2. Termination / cycle handling — what an evaluator does when paths produce infinite traversal or large cartesian products
3. Sandboxing — Adalbert's `deref` deals with this in his branch (PR Add adalbert-contracts: ODRL 2.2 profile for data governance #160); decide whether DPROD adopts the same approach or its own

Recommend resolving #186 first (it pins down the OWL semantics of `dprod:path` itself), then formalise the grammar here.

cc @tonyseale @matthiasautrata

[jgeluk]

Tony Seale recorded a proposed disposition in commit 9f9a044: reject the path-traversal sandboxing/grammar restriction for now because it appears minor and premature before real usage is known. This is now preserved here instead of in changes-plan.md.

This comment records the proposal; the issue should remain open until the group explicitly accepts or rejects it. Because evaluator security and termination are involved, omission must not become an undocumented permissive fallback.