Add dprod-contracts folder#156
Conversation
tonyseale
requested review from
FroehlichMarcel,
andrea-gioia,
jgeluk,
joshcornejo,
nvar and
rivettp
as code owners
Adds DPROD contract TTL files (ontology, shapes, examples), documentation, and supporting files. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Reformats the contracts ontology to match the styling of the main DPROD ontology: 2-space indentation, header comments block, @base declaration, Dublin Core annotation property declarations, rdfs:Class alongside owl:Class, rdf:Property alongside owl property types, dct:description instead of skos:definition, rdfs:comment instead of skos:note, lowercase rdfs:label without @en, prefix-form rdfs:isDefinedBy, and period terminator on its own line. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
tonyseale
force-pushed
the
add-dprod-contracts
branch
from
e48aeda to
c994721
Compare
Domain-specific terms (actions, operands, concept values) that each adopter would define themselves are moved out of the dprod: namespace into ex: (https://example.org/) across all 4 example TTL files. - 8 actions: deliver, notify, nonDisplay, report, conformTo, query, export, log - 12 operands: recipientType, classification, processingMode, environment, etc. - 14 concept values: internal, analytics, compliance, production, staging, etc. - Add @Prefix ex: declaration where missing - Rename section headers: "Inline DPROD Vocabulary" → "Inline Domain Vocabulary" - Fix baseline.ttl bug: restore missing ex:deliver subject IRI - Update dprod:select SPARQL string to use ex: namespace - Core dprod: framework terms (DataContract, Subscription, state, path, etc.) unchanged Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The Quick Start showed only a DataOffer but not the DataContract that activates it. Add a parallel example showing bilateral binding, acceptsOffer link, effective/expiration dates, and duties on both parties. Also includes pre-existing namespace fixes (dprod: -> ex: for domain vocab). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…d ontology Complete the namespace migration started in 1ae9ad6 (which covered example files). Domain-specific actions (deliver, notify, conformTo, report, nonDisplay), operands (classification, timeliness, recipientType, environment, etc.), and concept values (analytics, internal, realtime, etc.) now consistently use ex: rather than dprod:, reinforcing that these are domain vocabulary, not core profile terms. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
DCON equivalents and the full DCON->DPROD migration section are historical and no longer relevant to the current specification. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@tonyseale is attempting to deploy a commit to the EKGF Team on Vercel. A member of the Team first needs to authorize it. |
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- respec/template.html: drop duplicate "Matthias Autrata" from author list - dprod-contracts.ttl: add Matthias Autrata and Josh Cornejo as dct:contributor to mirror the core ontology - README, contracts.ttl, specification.md, formal-semantics.md: replace remaining "SHACL-style" with "SPARQL-style" (plan item 1.1, re-swept) - docs/temp.md → docs/recurrence-redesign.md (purpose-named filename while Bucket 4 is in flight; 4.8 deletion still planned) - .gitignore: drop /.idea/LNKD.tech Editor.xml (user-global, not project) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jgeluk
left a comment
jgeluk
left a comment
There was a problem hiding this comment.
Review — staging-branch housekeeping pass
Reviewed against develop after the latest develop merge (0e1a388) and the housekeeping commit 1dc3883. Treating this PR as the working space for Tony's slice of DPROD 1.1 data-contracts — not as a self-contained final standard. Matthias's parallel work in #160 covers a complementary slice.
What I checked
- Branch is up to date with
develop(no remainingdevelopcommits ahead of it). dprod-contracts/{dprod-contracts,dprod-contracts-shapes,dprod-contracts-prof}.ttlall re-parse cleanly withrdflib(187 / 344 / 21 triples).bash build.sh(i.e.spec-generator/main.py) runs end-to-end; the existing DPROD 1.0 (Beta) spec still generates.- Plan item 1.1 was marked PASS but six occurrences of "SHACL-style" were still in the source — those have now been swept in
1dc3883.
Housekeeping applied in 1dc3883
- Duplicate
"Matthias Autrata"removed fromrespec/template.htmlauthor list. - Matthias Autrata and Josh Cornejo added as
dct:contributorindprod-contracts.ttlto mirror the core ontology. - Final
SHACL-style → SPARQL-stylesweep acrossREADME.md,dprod-contracts.ttl,docs/specification.md,docs/formal-semantics.md. docs/temp.md→docs/recurrence-redesign.md(purpose-named filename while Bucket 4 is in flight; 4.8 deletion still planned)..gitignore: dropped/.idea/LNKD.tech Editor.xml(belongs in user-global gitignore).
Open questions for the group (not blocking this PR, but next steps)
These all live in dprod-contracts/docs/changes-plan.md; flagging here so they're visible from the PR conversation rather than buried in the file.
- Bucket 4 — recurrence redesign. Drafted in
docs/recurrence-redesign.md. Worth executing as its own follow-up PR rather than continuing to expand this one. - Bundle 5.7 / 5.8 / 5.9 — Stephen's three coupled questions (
DataDutysubtype,DataOffertarget cardinality,DataContractacceptsOffer basket model). The plan correctly notes 5.8 + 5.9 are tightly coupled; 5.7 likely wants to ride along. - 5.4 / 5.5 —
dprod:pathOWL typing (untyped today asrdf:Property);dprod:selectis defined but unused in any example — implement, mark non-normative, or delete? - Spec-generator integration timing. Currently
dprod-contracts/is not loaded byspec-generator/main.py(deliberate while the design is in flight). Worth deciding now whether the wiring lands in this PR before merge, in a follow-up PR after Bucket 4 + 5.7-5.9 resolve, or in a single integration PR after both #156 and #160 are accepted.
Recommendation
This is a high-quality, well-documented contribution and the housekeeping leaves it in a tidy state. I'd suggest:
- Land Bucket 4 (recurrence redesign) as a separate PR against
add-dprod-contracts. - Run the 5.7 / 5.8 / 5.9 bundle past the group in a single message, then merge the decisions into this branch.
- Decide the spec-generator integration plan with #160's author.
Once 5.7-5.9 are resolved and Bucket 4 is in, this PR is in good shape to merge into develop even if some lower-priority Bucket 5 / Bucket 6 items remain — they can continue evolving on develop via follow-up PRs.
|
Decision recorded — spec-generator integration: wiring lands in this PR, not deferred. Each contracts PR is responsible for its own spec-generator wiring (#156 wires Cc @tonyseale — happy to take a first crack at wiring |
Repoints contracts namespace from https://ekgf.github.io/dprod/ to the canonical https://www.omg.org/spec/DPROD/ so contracts terms unify with the core DPROD vocabulary (fixes plan item 5.1 — Tony's verbal intent was right but he kept the old EKGF GitHub Pages IRI). Spec-generator changes: - functions.load_ontologies() now also parses dprod-contracts.ttl, dprod-contracts-shapes.ttl, and dprod-contracts-prof.ttl into the main graph so contracts node-shapes are rendered as spec classes - load_dprod_ontology() and load_dprod_shapes() include contracts so dprod.jsonld / dprod.rdf / dprod-shapes.* outputs cover them too - globals.contracts_shapes_ns_iri added for the new prefix binding - main.add_to_context() skips NodeShapes without sh:targetClass (NonEmptyClausesConstraint, the sh:targetSubjectOf reject shapes) and skips Reject*Shape patterns that target ODRL classes purely to forbid them — they would otherwise render as empty spec sections (Ticket, Request, AssetCollection, PartyCollection) - reorder_list includes the contracts classes after the core ones - dprod-contracts*.ttl files are copied into dist/ ReSpec template: - edDraftURI points to https://ekgf.org/spec/{{ branch }}/ so the "Latest editor's draft" header link surfaces the per-branch preview on ekgf.org Verified: build emits dist/index.html with sections for DataOffer, DataContract, Policy, Set, Offer, Agreement, Permission, Prohibition, Duty, Constraint, LogicalConstraint, LeftOperand alongside the core DPROD classes; no Reject* noise. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Spec-generator wiring done — commit Two coupled changes: 1. Namespace alignment. Contracts terms were minted under 2. Spec-generator integration.
3. Editor's draft link. The branch preview at https://ekgf.org/spec/add-dprod-contracts/ should pick this up on next Vercel build. |
ProfilePropertyGroup and StatePropertyGroup are PropertyShapes reused across multiple class shapes via sh:property. They previously had no sh:name / sh:description, so the spec rendered them as empty "profile" and "state" entries with "None" descriptions inside every host class section. Add user-facing labels and descriptions so the rendered spec shows what each reused property requires. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jgeluk
left a comment
jgeluk
left a comment
There was a problem hiding this comment.
Approving for merge into `develop`.
The branch is in good shape: ontology + shapes parse cleanly, the spec generator now renders the contracts vocabulary (DataOffer, DataContract, Policy, Set, Offer, Agreement, Permission, Prohibition, Duty, Constraint, LogicalConstraint, LeftOperand) alongside the core DPROD classes, the namespace is aligned with the canonical OMG IRI, the editor's draft link points at the per-branch ekgf.org preview, and all CI checks are green on the latest SHA.
The outstanding design items from `dprod-contracts/docs/changes-plan.md` are being split out into separate tracking issues — they can keep evolving on `develop` via follow-up PRs without holding this contribution any longer. Bucket 4 (recurrence redesign), 1.3 follow-on (DutyState/ContractState split), and the 5.x design questions (5.4 `dprod:path` typing, 5.5 `dprod:select`, 5.7 DataDuty subtype, 5.8/5.9 cardinality bundle, 6.2 path sandboxing) will each get their own issue so we can prioritise and assign them independently.
Thanks @tonyseale for the substantial, thoughtfully iterated contribution.
|
Outstanding items from `dprod-contracts/docs/changes-plan.md` are now tracked as separate issues so they can be prioritised and assigned independently after merge:
The `changes-plan.md` file stays on the branch as the historical triage record. Once these issues are individually resolved their corresponding entries can be marked closed in the plan, but new design discussion should happen on the issues from here on. Ready to merge. |
## Summary - Add \`@matthiasautrata\` as a code owner (active contributor to data-contracts work via PR #160 and review feedback on PR #156) - Remove \`@nvar\` and \`@andrea-gioia\` - \`@joshcornejo\` was already an owner, no change there ## Effect Affects future PRs targeting \`develop\`: \`@matthiasautrata\` will be auto-requested as a reviewer; \`@nvar\` and \`@andrea-gioia\` will no longer be. The \`main\` copy of CODEOWNERS is unchanged for now — it'll get synced at ballot time when the next merge from \`develop\` lands on \`main\`. ## Test plan - [ ] Confirm the new owner set is what you want before merging - [ ] After merge, open a throwaway PR against develop to verify the auto-requested reviewer set updates as expected (optional) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jgeluk
requested review from
matthiasautrata
and removed request for
andrea-gioia and
nvar
|
@rivettp @FroehlichMarcel @joshcornejo @matthiasautrata — fresh review needed to unblock merge. Branch protection on `develop` requires the last push to be approved by a code owner other than the pusher. The branch was just brought up to date with develop (which dragged in the CODEOWNERS update from #191) and the latest commit was pushed under my credentials, so my earlier approval no longer satisfies the rule. The PR itself is fully green otherwise — all CI checks pass on the latest SHA, the dprod-contracts ontology and shapes are wired into the spec generator, the branch preview is at https://ekgf.org/spec/add-dprod-contracts/, and the seven outstanding design items have been split out as their own tracking issues (#184–#190). Anyone of you approving will let this merge into develop. Thanks. |
…#199) ## Summary Follows on from #156 (merged 2026-05-28). Resolves two open `changes-plan.md` items: - **§5.5 — `dprod:select` removed.** Every documented use was a verbatim restatement of an existing `dprod:path` sequence; the few SPARQL-only capabilities (filters, joins, aggregates, inverse/alternative traversal) are unexercised by any policy in `dprod-contracts/examples/`; and the previous specification was underdefined when measured against SHACL's `sh:SPARQLConstraint` machinery (variable-name inconsistency `?v` vs `?value`, no prefix mechanism, contradictory composition with `dprod:path`, hand-waved multi-row and graph-context semantics). Future-revisit trigger and the SHACL-rigour template are recorded in `changes-plan.md` §5.5. - **§1.3 — `dprod:State` class and `dprod:state` union-domain property removed.** Replaced with three domain-specific object properties: - `dprod:offerLifeCycleStatus` on `dprod:DataOffer` - `dprod:contractLifeCycleStatus` on `dprod:DataContract` - `dprod:dutyState` on `odrl:Duty` Range on all three is the open class `skos:Concept`. This preserves the group's open-world intent better than the originally-discussed subclass split, and aligns with how DPROD already uses `skos:Concept` for operands and actions. The four canonical state individuals (`dprod:Pending`, `dprod:Active`, `dprod:Fulfilled`, `dprod:Violated`) are retyped from `dprod:State` to `skos:Concept` and grouped into a new example `skos:ConceptScheme`, `dprod:DataContractLifeCycleStatus` — shipped as one ready-made vocabulary that implementations are free to use, extend via `skos:inScheme`, or replace entirely. Property descriptions lead with the distinguishing question each property answers — *publication lifecycle (assigned by publisher)* vs *administrative lifecycle (assigned by contract management)* vs *evaluation result (computed by an evaluator)* — surfacing the declared-vs-computed contrast that was previously hidden. ### Side-effects also landed in this PR - **SHACL shape for `dprod:path` value structure (`changes-plan` §2.3, also closed).** `LeftOperandShape` now constrains `dprod:path` to a single IRI or an `rdf:List` of IRIs via `sh:or`, with a non-recursive `dprod-shapes:RdfListOfIris` helper that walks the list using `( [ sh:zeroOrMorePath rdf:rest ] rdf:first )` — avoids pyshacl's `ShapeRecursionWarning` (which fires on the naïve recursive variant at depth 14). - **State-shape split.** `dprod-shapes:StatePropertyGroup` (with closed `sh:in` over the four states) replaced with `OfferLifeCycleStatusPropertyGroup`, `ContractLifeCycleStatusPropertyGroup`, `DutyStatePropertyGroup` — each constraining `sh:maxCount 1` and `sh:nodeKind sh:IRI` (no enumeration; the `rdfs:range skos:Concept` in the ontology remains the authoritative range). - **Examples rewritten by enclosing-entity type.** 9 `dprod:state` assertions in `baseline.ttl` became `dprod:offerLifeCycleStatus`, 6 became `dprod:dutyState`; in `data-contract.ttl` 1 became `dprod:offerLifeCycleStatus` and 3 became `dprod:dutyState`; single offer-status replacements in `odcs.ttl` and `contracts-guide.md`. - **Doc sweep.** `README.md`, `docs/specification.md` (§3.1 Example Lifecycle Concept Scheme, §3.2/§3.3 Recommended properties, §4.1 grouped property table, property-incidence matrix), `docs/overview.md`, `docs/term-mapping.md`, `docs/contracts-guide.md`, `examples/odcs.md`, `docs/policy-writers-guide.md` all updated. Detailed DONE entries appended to `changes-plan.md` §§1.3, 2.3, 5.5. Diff: 16 files, +333 / −184 (14 contracts files scoped to `dprod-contracts/`, plus the validation tooling noted below). ### Added by maintainer (jgeluk) - **Rebased onto current `develop`** to resolve the merge conflicts (the branch had diverged before #156's squash-merge landed; the rebased tree is byte-identical to the prior fork tip — no content changed). - **`dprod-contracts/validate.py` + `pyshacl` dep** added: parses every contracts TTL and SHACL-validates each example against the shapes (ontology as `ont_graph`, RDFS inference on); exits non-zero on any parse error or violation. Confirms the new SKOS lifecycle shapes/examples validate cleanly, and is wired for CI in #200. ## Test plan - [x] `dprod-contracts.ttl` and `dprod-contracts-shapes.ttl` parse cleanly (rdflib, 569-triple combined graph). - [x] All four example policies — `baseline.ttl`, `data-contract.ttl`, `data-use-policy.ttl`, `odcs.ttl` — validate under the updated shapes with `conforms=True` and zero `ShapeRecursionWarning`. - [x] Negative path tests: a `LeftOperand` whose `dprod:path` is a literal triggers a violation; a sequence containing a literal triggers a violation. - [x] Positive path tests: bare IRI and `rdf:List` of IRIs both accepted. - [x] Sweep confirms no remaining functional references to `dprod:select`, `dprod:state`, or `dprod:State` outside `changes-plan.md` historical context entries. - [ ] Spec generator build (CI) — to confirm the spec still generates without warnings now that `dprod:select` and `dprod:State` are gone from the property-incidence matrix. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Jacobus Geluk <jacobus.geluk@ekgf.org>
3 participants
Summary
Introduces
dprod-contracts/— a self-contained ODRL 2.2 profile that extends DPROD with deterministic data-governance semantics. Destined for DPROD 1.1 once the design stabilises ondevelop; this PR is the working space for that.The work has been actively iterated with review rounds from Matthias Autrata and Stephen — full status of every reviewer item is tracked in
dprod-contracts/docs/changes-plan.md.Scope
DPROD 1.1's contracts story is being decomposed across multiple feature branches. This PR is one contribution; Matthias's #160
add-adalbert-contractsis a parallel/complementary approach landing in its own folder. Neither branch needs to be the final word on contracts — both targetdevelop, and final integration (including wiring intospec-generator/main.py) will happen once the design crystallises.What's in the branch
Ontology + shapes
dprod-contracts.ttl— OWL profile:DataOffer,DataContract,RuntimeReference, lifecycleStateenum, duty role properties, deadline/recurrence, logical negation, asset/party hierarchydprod-contracts-shapes.ttl— SHACL validation: policy/rule/contract/operand shapes and explicit rejection shapes for unsupported ODRL constructsdprod-contracts-prof.ttl— DXPROF profile descriptor withprof:isProfileOf odrl:coreExamples
examples/data-contract.ttl— bilateral DataOffer + DataContractexamples/data-use-policy.ttl— role-based access with purpose constraintsexamples/baseline.ttl— broader test policy setexamples/odcs.ttl+odcs.md— ODCS interop walk-throughDocumentation
docs/specification.md— normative vocabulary referencedocs/formal-semantics.md— evaluation semantics, amenable to Dafny/Why3/Coqdocs/contracts-guide.md,docs/policy-writers-guide.md,docs/overview.md— guidesdocs/term-mapping.md— DPROD ↔ ODRL/DCAT/ODCS term mapdocs/changes-plan.md— live triage of reviewer feedback (Matthias, Stephen)docs/recurrence-redesign.md— drafted Bucket 4 redesign (RFC 5545 RRULE-based recurrence), pending executionCore repo
ontology/dprod/dprod-ontology.ttl— new contributor entriesrespec/template.html— editor / author list updatesBuild impact
dprod-contracts/is not yet wired into the spec generator — this is deliberate while the design is still in flight.build.shcontinues to produce the current DPROD 1.0 (Beta) spec unchanged.Outstanding (tracked in
changes-plan.md)docs/recurrence-redesign.md)dprod:pathtyping), 5.5 (dprod:selectkeep/remove), 5.7 (DataDutysubtype), 5.8 / 5.9 (DataOffer / acceptsOffer cardinality — Stephen's basket-model proposal)🤖 Generated with Claude Code