Re: constraining parties and leftOperands

I am looking for a constraint-based model for the tuples of [action -> parties] to prevent the following 2 situations:
As your catalogue of policies grows (policies + roles + departments + parties), it will create unnecessary rules that need to be managed and tracked in sets (extra admin + more chance of errors).
If I want to map to the control layer in REGO (OPA) or CEL (FGA), I have N ODRL rules = 1 REGU/CEL rule (N = number of parties) – now my ‘mapper’ has to be extra smart to bound to the output (complex), or I will have a larger (unnecessary) ruleset to test (runtime inefficient).
Regards,

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain

 

From: Renato Iannella <r@iannel.la>
Date: Thursday 13 June 2024 at 04:04
To: "public-odrl@w3.org Group" <public-odrl@w3.org>
Subject: Re: constraining parties and leftOperands
Resent-From: <public-odrl@w3.org>
Resent-Date: Thu, 13 Jun 2024 03:04:29 +0000

 

I may have missed some complexity, but would this work:

 

ex:policy001 a odrl:Agreement ;

    odrl:assigner <http://example.com/party:owner> ;

    odrl:target <http://example.com/asset:1> ;

    odrl:permission [

        odrl:assignee <http://example.com/party:user> ;

        odrl:action odrl:play

    ] ;

    odrl:permission [

        odrl:assignee <http://example.com/party:administrator> ;

        odrl:action odrl:transform

    ] .

 

Cheers - R

 

 



On 12 Jun 2024, at 18:30, Joshua Cornejo <josh@marketdata.md> wrote:

 

Thanks,

 

Discarding that operand, the original question remains unanswered.

 

How can I model these common restrictions with the current LeftOperand taxonomy:

 
ex:User (Renato) can odrl:play an Asset (read) , but ex:Administrator (Victor) can odrl:transform (read/write)?
 

 

<image001.png>

 

 

If odrl:industry wasn’t so narrowly defined, it could fit the purpose.

 

 

Regards,