Open acceptsOffer to multiple DataOffers in 5.9 pattern#212
Conversation
… ex-environment. This is bringing up quite large questions actually around the fact that we're not formally modelling the semantics of requests.
…d that it would be an advanced feature for someone to put in a request for a new obligational duty, but there's no reason that we should stop that from happening.
…xCount 1 and update message to guide composition consistency: single-resource-per-offer or multi-resource approach, but maintain one pattern throughout. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
matthiasautrata
left a comment
matthiasautrata
left a comment
There was a problem hiding this comment.
It stretches an ODRL invariant. DataContract subclasses odrl:Agreement, and both AgreementShape and DataContractShape require exactly one assigner and one assignee. ODRL 2.2's Offer→Agreement relationship is canonically 1:1. Removing acceptsOffer's maxCount 1 breaks that without requiring the bundled offers to share the contract's assigner — nothing stops you from "basketing" offers from different providers under one bilateral agreement.
Three options, ranked by how well they fit without adding machinery:
Use what's already there. DPROD ships dprod:partOf — a transitive Asset hierarchy. Model the basket as one Offer whose target is a composite Asset with multiple partOf parts, instead of one Agreement accepting several Offers. Keeps the 1:1 Offer→Agreement invariant intact, keeps rule provenance unambiguous (one offer, one rule set), needs zero new classes. This solves the same-provider basket case for free.
Umbrella class, as you suggested — a Bundle/Basket that aggregates several clean 1:1 DataContracts, rather than one Agreement referencing N Offers. Necessary if the real requirement is cross-provider baskets (different assigners), which asset composition can't express since one Offer has one assigner. Keeps each contract's rules traceable to exactly one offer.
The PR's approach — loosen acceptsOffer — is the cheapest patch but leaves rule-merging undefined and doesn't constrain assigner consistency across the bundled offers.
So, I disagree. This is just a bad ide. Personally, I would accept a "shopping cart" model: Multiple offers turn into multiple agreements and are consolidated. Think receipt or invoice. But the individual products don't just suddenly form a new, merged agreement.
3 participants
Summary
Remove
sh:maxCount 1constraint fromdprod:acceptsOfferonDataContractShapeto allow multiple DataOffers per contract (basket model for 5.9).Updated the validation message to guide composition consistency: users should maintain one pattern throughout — either single-resource-per-offer DataOffers, or multi-resource DataOffers, but not mix approaches.
Changes
sh:maxCount 1on acceptsOffer property shape and updatedsh:messageto capture the composition pattern principleThis change supports the 5.9 decision to allow contracts to accept multiple offers as a basket, enabling better offer reuse and consumer composition without forcing duplicate contracts.
🤖 Generated with Claude Code