odrl:collate (suitable for 3.0)
the term odrl:NextPolicy doesn’t address an ecosystem where an odrl:Assignee now can become an odrl:Assigner and needs a way to reference the odrl:Agreement (which is now inside the ecosystem some immutable reference odrl:Offer) and convert their new policies into their own odrl:Offer.
Sequence looks something like:
ex:Assigner1 -> ex:Aggreement -> ex:Assignee1 -> ex:ReferenceOffer -> odrl:collate -> ex:AssigneeNewOffer
There are differences between failure and consequences when taken the point of view is that of internal and external policies. For example i can decide to execute an action that is within a prohibition if it is internal, but not if it is external.
ex:PolicyEx a odrl:Offer;
odrl:collate xx:ExternalReferencePolicy.
Hi @joshcornejo, can you give a bit more detail into what you would want to do with a term like collate?
From your given example, I can't deduce what needs to be modelled. Is it to filter which actions can be done, hence you proposing a new type of left operand? Is it an action? Is it something else? Is it just to differenciate between internal or external policies?
A concrete example would help to assess if this is something that we should include in the Community Vocabulary work.
There is also http://purl.org/dc/terms/references to connect related policies.
The chain:
ex:Assigner1 -> ex:Aggreement -> ex:Assignee1 -> ex:ReferenceOffer -> odrl:collate -> ex:AssigneeNewOffer
Assignee1 is incapable of "handpicking" rules from ex:Aggreement via nextPolicy nor inheritFrom, if a new odrl:set is created, then still it is not connected to the original aggreement. Meaning there is a break in the supply chain.
This is for version 3.0!