Re: Assigners and inheritFrom policies

Hi Josuha, thanks for the additional information….

In the diagram, is the second odrl:Offer inheriting from the first odrl:Agreement?
I would expect that to create some semantic inconsistencies.

Also, when you mention “roles”, are you referring to the odrl:function property: https://www.w3.org/TR/odrl-model/#function

What "transitive relationships” would occur...as the functional roles would explicitly appear in the new policy (as they were inherited downstream)

Cheers - R

> On 26 Apr 2024, at 21:15, Joshua Cornejo <josh@marketdata.md> wrote:
> 
> More on practical use cases ☹
>  
> IMHO:
>  
> As an Assigner party (‘the owner of the offer’) I should be able to define what are the roles as it goes through transitive relationships across policy execution, at a minimum a formal way to establish the way transform myself from “odrl:Assigner” in the transformation from odrl:Offer to odrl:Agreement to “something:Something” in a following conversion in a possible odrl:Offer from the odrl:Assignee that is part of the odrl:Agreement.
>  
 
>  
> As I’m playing with deep graphs for odrl:inheritFrom, I am finding that I have too many Assigners and it starts to get semantically thin who’s who and why are they all there.
>  
> An odrl: LeftOperand (probably associated with a odrl:Action?) could determine the sequence as pairs following a transition as a list < role1, role2, … finalRole >. Each new subsequent odrl:Offer generated by the next party in the chain removes the entry (until there is only 1 left as determined by the original sequence).
>  
> (I also think an odrl:Collate concept makes sense for those transitions).
>  
> Thoughts appreciated.
> ___________________________________
> Joshua Cornejo
> marketdata <https://www.marketdata.md/>
> embed open standards 
> across your supply chain
>  
>