Re: Assigners and inheritFrom policies

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

embed open standards 

across your supply chain

 

From: Joshua Cornejo <josh@marketdata.md>
Date: Monday 22 April 2024 at 08:07
To: Renato Iannella <r@iannel.la>
Cc: "public-odrl@w3.org" <public-odrl@w3.org>
Subject: Re: Assigners and inheritFrom policies
Resent-From: <public-odrl@w3.org>
Resent-Date: Mon, 22 Apr 2024 07:07:10 +0000

 

I saw the example – but it has only 1 assigner.

 

As I go through practical use cases:
inheritFrom is useful for Set/Offer.
A ‘Collate’ type concept would be better for the Agreement.
I reason that a user (and likely different types of users)  goes through the supply chain:
As a stakeholder defining the rights and obligations of my asset,  I want to build a hierarchy for the grouping of rules to simplify my work. ‘Inheriting’ is a natural concept to go from generalisation to specialisation (building Set/Offer “trees”).
As a stakeholder in a buying process, I want to select a group of assets from an organisation and generate the least amount possible of documents (policies) to manage my relationship between buyer and seller. The concept of ‘inheritance’ doesn’t fit semantically in that part of the business process, when I buy I go through a ‘shopping cart’ concept and ‘collate’ all the items (or as many as possible that share something common) I want to purchase and get one ‘contract’.
I see a very close relationship between:
odrl:Offer and fibo-fnd-agr-ctr:ContractualElement 
(def: element, such as an arrangement, provision, requirement, rule, specification, and standard that forms an integral part of an agreement) 
odrl:Aggreement and fibo-fnd-agr-ctr:ContractualCommitment 
(def: contractual commitments include general conditions which are common to all types of contracts, such as general and special arrangements, provisions, requirements, rules, rights and obligations, specifications, and standards that form an integral part of an agreement or contract, as well as special conditions which are peculiar to a specific contract (such as, contract change conditions, payment conditions, price variation clauses, penalties).)

 

And from fibo-fnd-agr-ctr:ContractualCommitment,  the wrapping of everything inside a (legal machine-readable document instance of) fibo-fnd-agr-ctr:Contract would be the next natural step.

 

It is a shame that the naming conventions turn confusing – as the FIBO:Agreement ontology aligns with ODRL:Offer, whilst FIBO:Contract would align with ODRL Agreement.

 

Regards,

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain

 

From: Renato Iannella <r@iannel.la>
Date: Monday 22 April 2024 at 02:15
To: Joshua Cornejo <josh@marketdata.md>
Cc: "public-odrl@w3.org" <public-odrl@w3.org>
Subject: Re: Assigners and inheritFrom policies
Resent-From: <public-odrl@w3.org>
Resent-Date: Mon, 22 Apr 2024 01:15:48 +0000

 

Hi Joshua, please see the inheritance example here: https://www.w3.org/TR/odrl-model/#inheritance

 

In your use case assumptions:

 - correct

 - yes (PartyA and B are the assigners for Rules in Policy B) - Policy A does not change

 - PartyA will also be the assigner of PolicyB Rules (as Party A is defined at the “policy-level”)

 

Cheers - Renato

 




On 19 Apr 2024, at 22:37, Joshua Cornejo <josh@marketdata.md> wrote:

 

Always in the scope of Offer definition.

 
PartyA and PartyB belong to the same organisation (could be units)
PartyA is the Assigner in PolicyA.
PartyB is the Assigner in PolicyB.
PolicyB - inheritFrom -> PolicyA.
 

I am assuming:
there is no restriction for this use case.
For each Rule in PolicyA that is now referenced in PolicyB, the Assigner is now a list of (PartyA, PartyB),
Rules that are defined in PolicyB, only have PartyB as the Assigner.
 

Is this correct?

 

I know there is a section for the use case of ‘not the same organisation’ as roles change (where the functions vocabulary is expanded, but not focused on that at this stage).

 

Regards,

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain