Re: Assigners and inheritFrom policies

I thought about this more over the weekend, because it is not about ‘the structures available to defining roles’.  I agree with the semantic inconsistencies and hence why I raise the questions. My ‘test’ is all internal – but when I see the RDF I have 7 odrl:assigner and that triggered the thought,

 

So yes, I refer to roles, but as I said, not that roles ‘can be defined’ –that is a syntactical/structural definition (semantics about how things are shaped). I think my problem is a ‘step’ forward to defining a protocol that uses those shapes to guarantee that a Party will have ‘a say’ around the role(s) in subsequent (indirect) Agreements.

 

As an example:

 
Party A is a producer and sells to Party B.
Party B buys from multiple producers and sells “a bag of products” to Party C.
Party A (or any other party that sells to B) wants to be part of the “chain” implicitly in a specific role (in the contract with B = it was an odrl:Assigner with B, but now it could be ex:Mentioned).
 

My thinking (so far) points to a formal odrl:LeftOperand with use as part of the constraints:
In an odrl:action - A Party might want to take different roles depending upon the action – for example ex:informed when odrl:use / but ex:null when it is odrl:payAmount).
In an odrl:target – A Party might want (or need) to be ex:notified to ‘allow’ access to the product.
I am not talking about the functions themselves (those could vary, as long as they are odrl:function) – I am only talking about the ability for a Party to determine it’s roles at the point of definition of an odrl:Offer.
 

Finally:
To keep ‘a formal lineage consistency’ I probably need to ‘ingest’ the odrl:Agreement generated by Party A as a starting point for Party B. odrl:inheritFrom, doesn’t look appropriate, I would prefer a different element - like odrl:collate, with this artefact I can build more complex policies from my suppliers, and differentiate between ‘their’ and ‘my’ policies without having to start from scratch (or cutting ties, as in some cases the ‘flow’ of accountability for lineage should be open-ended).
 

IMHO - this would be useful in the use cases where the supply chain is large and tangled (many Parties supply many Assets to distributors/aggregators that repackage them) as it allows the ‘middleman’ to reduce manual analysis and the risk of compliance breaches.

 

Regards,

 

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain

 

From: Renato Iannella <r@iannel.la>
Date: Monday 29 April 2024 at 06:06
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, 29 Apr 2024 05:06:00 +0000

 

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

embed open standards 

across your supply chain