Skip to content

Integrate Data Contracts into the specification - #259

Merged
matthiasautrata merged 7 commits into
developfrom
issue/258-spec-contracts
Sep 24, 2026
Merged

matthiasautrata merged 7 commits into
developfrom
issue/258-spec-contracts

Conversation

@tonyseale

Copy link
Copy Markdown
Contributor

Resolves: #258
Also resolves #240, #239 and #197, and records a namespace decision on #232.

Summary

  • Data Contracts in the spec. The contracts profile renders as its own part of the specification: contracts classes and extension properties from the contracts shapes, a generated model diagram, and seven worked examples under examples/contracts/ ordered so each builds on the last. Only DPROD-defined classes render as class definitions; the profile's constraints on ODRL classes are described in prose. The JSON-LD context now covers the contracts vocabulary.
  • Namespace moved to https://ekgf.org/dprod/spec/develop/. The namespace IRI and the URL that serves the artifacts must match, and the OMG spec URL serves only the catalogue page (DPROD artifacts fail to resolve at their OMG NS URLs. Return 404 #232). Every IRI rooted at the OMG URL moves with it: vocabulary, shapes, contracts shapes, data namespace, ODRL profile IRI, version IRIs and every example @context. This also reverses the .../DPROD/dprod/ move from Ontology IRI: move vocabulary to DPROD/dprod and drop hyphens from versioned URIs #204. The ReSpec latestVersion link stays on the OMG catalogue entry; the archived 1.0 snapshot is unchanged.
  • DPROD Contracts: define bearer binding for subjectless duties #240 duty bearer. dprod:subjectOfDuty documents that an omitted bearer defaults to the data product owner.
  • DPROD Contracts: reject duty-only properties on non-Duty rules #239 duty-only properties. New DutyOnlyPropertiesShape rejects dprod:deadline, dprod:recurrence, dprod:subjectOfDuty and dprod:objectOfDuty on a Permission or Prohibition, with explicit sh:not checks so RDFS inference from the OWL domain cannot make a misused rule conform. Regression tests cover all eight misuse cases plus valid named and inline duties.
  • DPROD Contracts: reject per-policy odrl:conflict override (2.4) #197 conflict strategy. odrl:conflict odrl:prohibit on the profile is documented as the default; a policy may declare its own odrl:conflict to override. No SHACL rejection.

Verification

  • python -m unittest discover -s tests: 22 pass
  • python -m unittest discover -s dprod-contracts/tests: 49 pass
  • dprod-contracts/validate.py: all examples validate
  • Spec generator builds; every example expands against the live dprod-context.jsonld on ekgf.org with no local substitution

Notes for reviewers

  • Term IRIs such as .../develop/DataProduct and the shapes/ and data/ sub-paths still 404 on ekgf.org, as they did on OMG. Dereferencing terms needs routing on the site and is out of scope here.
  • When Implement reusable Schedule model #234 (Schedule model) lands, drop dprod:recurrence from DutyOnlyPropertiesShape.

🤖 Generated with Claude Code

tonyseale and others added 7 commits September 24, 2026 16:48
State on dprod:subjectOfDuty that an omitted bearer defaults to the
dprod:dataProductOwner of the data product the policy applies to.

Resolves: #240

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Add DutyOnlyPropertiesShape, targeting the subjects of dprod:deadline,
dprod:recurrence, dprod:subjectOfDuty and dprod:objectOfDuty. The subject
must be an odrl:Duty and must not be an odrl:Permission or
odrl:Prohibition, so the OWL domain can no longer silently infer a
second, ODRL-disjoint rule type onto a misused rule.

Regression tests cover each property on a Permission and a Prohibition,
and keep valid named and inline duties conformant.

Resolves: #239

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ROD/

Reverts the vocabulary move to .../DPROD/dprod/ made for #204 in #205.
The OMG namespace for the ontology is the bare spec IRI; the /dprod/
segment was introduced only for symmetry with /shapes/ and is not the
published namespace. The versioned ontology IRI follows suit
(.../DPROD/20260601/). The shapes, contracts shapes and data namespaces
are unchanged, as is the archived 1.0 snapshot under site/public.

Applied across the ontology, shapes, contracts profile, examples, docs,
tests, the spec generator namespace constant and the ReSpec template.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The OMG spec URL serves only the catalogue page: dprod-context.jsonld
and the ontology files 404 there (#232), so no example could be
expanded from its published @context. Point every example, the spec
document, the adopt page and the example test at
https://ekgf.org/dprod/spec/develop/dprod-context.jsonld, which serves
the context as application/ld+json with open CORS. Verified by
expanding every example against the live context with no local
substitution.

The vocabulary namespace stays https://www.omg.org/spec/DPROD/; only
the artifact location changes. The retired-URL test now also rejects
the OMG context URL.

Relates to #232, #246

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The namespace IRI and the URL that serves the artifacts must match, and
https://www.omg.org/spec/DPROD/ serves nothing but the catalogue page
(#232). Until OMG hosts the artifacts, the namespace is the develop
spec URL on ekgf.org, which serves the spec, the ontology and shapes in
Turtle, JSON-LD and RDF/XML, and the JSON-LD context.

Every IRI rooted at the OMG spec URL moves with it: the vocabulary,
the shapes and contracts shapes namespaces, the data namespace, the
ODRL profile IRI and the version IRIs. The ReSpec latestVersion link
stays on the OMG catalogue entry, which is a document link rather than
a namespace. The archived 1.0 snapshot under site/public is unchanged.

Relates to #232, #210

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The profile's odrl:conflict odrl:prohibit is documented as the default:
if a permission and a prohibition both match, the prohibition wins. A
policy may declare its own odrl:conflict to override that default for
its rules. No SHACL rejection is added; a per-policy override validates.

Resolves: #197

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Render the Data Contracts profile as its own part of the spec: the
contracts classes and extension properties from the contracts shapes,
a generated model diagram, and seven worked examples under
examples/contracts/ ordered so that each builds on the last. Only
DPROD-defined classes render as class definitions; the profile's
constraints on ODRL classes are described in prose. The JSON-LD
context now covers the contracts vocabulary.

Resolves: #258

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@vercel

vercel Bot commented Sep 24, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
dprod Ready Ready Preview Sep 24, 2026 4:53pm UTC

@matthiasautrata
matthiasautrata merged commit cd6e07a into develop Sep 24, 2026
6 checks passed
@tonyseale

Copy link
Copy Markdown
Contributor Author

Review requested from the DPROD team: please review the Data Contracts part of the specification in particular.

Where to look

  • Rendered spec for this branch: https://ekgf.org/dprod/spec/issue-258-spec-contracts/ (the preview deploys after the branch build; if it 404s, try again shortly). The Data Contracts part is its own section, with the model diagram, the contracts classes and extension properties, and seven worked examples in order: Data Offer and Contract, Provider Duties, Lifecycle and Versioning, Data Use Policy, Collections and Target Inheritance, Evaluation Context, ODCS Mapping.
  • Source: dprod-contracts/dprod-contracts.ttl, dprod-contracts/dprod-contracts-shapes.ttl, dprod-contracts/docs/specification.md and the examples under examples/contracts/.

Questions the review should answer

  1. Does the Offer → Contract model (assigner, assignee, dprod:acceptsOffer, lifecycle status) read clearly to someone who has not followed the issues?
  2. Duties: is the bearer default to the data product owner (DPROD Contracts: define bearer binding for subjectless duties #240) and the duty-only property rule (DPROD Contracts: reject duty-only properties on non-Duty rules #239) the right call?
  3. Conflict: prohibition wins by default with a per-policy odrl:conflict override (DPROD Contracts: reject per-policy odrl:conflict override (2.4) #197). Agree?
  4. Are the seven examples the right set, and in the right order, for a first reader?
  5. Anything in the ODRL profile that an ODRL processor would trip over?

Comments inline on the diff or here in the thread are both fine.

tonyseale pushed a commit to matthiasautrata/dprod that referenced this pull request Oct 29, 2026
A readability pass over the text added in EKGF#259 and EKGF#261:

- Prohibition-wins is the profile's default conflict strategy, not a
  fixed rule (EKGF#197, EKGF#279). The overview bullet and the data use policy
  example now say "by default".
- The deterministic-evaluation bullet leads with its claim and is split
  into sentences.
- The overview says that lifecycle status and duty state share the same
  four optional concepts but use different properties, which the
  "kept apart on purpose" sentence left unexplained.
- A DPROD-aware processor "evaluates" rather than "enforces" (EKGF#263).
- The figure sentence had an "it" with no antecedent.
- Two descriptions went stale when EKGF#261 simplified the examples: the
  data offer example has no domain vocabulary, parties or duty
  instances, and only some examples declare terms inline.
- The data offer README listed four points after "Three things", and
  repeated the spec's note on plain ODRL names almost verbatim.
- Typos: "soem", "[[dprod]]]".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch was successfully deployed

1 active deployment
Preview — bd107a2c Deployed Sep 24, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Integrate Data Contracts into the DPROD specification DPROD Contracts: define bearer binding for subjectless duties

2 participants