Re: constraining parties and leftOperands

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)?
 

 

 

 

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

 

 

Regards,

 

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain

 

From: Renato Iannella <r@iannel.la>
Date: Wednesday 12 June 2024 at 03:19
To: "public-odrl@w3.org Group" <public-odrl@w3.org>
Subject: Re: constraining parties and leftOperands
Resent-From: <public-odrl@w3.org>
Resent-Date: Wed, 12 Jun 2024 02:19:24 +0000

 

The odrl:recipient is defined as "The party receiving the result/outcome of exercising the action of the Rule”.

So they are not the parties that actually exercise the permission action - they are be beneficiaries from some of other party (assignee) performing the action.

 

Here is an example:  https://github.com/besteves4/odrl-access-control-profile/blob/main/examples/app-policy-ex-2.ttl

 

Cheers…R



On 11 Jun 2024, at 17:50, Joshua Cornejo <josh@marketdata.md> wrote:

 

Back to my original question – these group/role intersections are common operations in rights management and I am looking at understanding how it originally was thought to be addressed (is the approach of constraints on permissions/prohibitions at asset level via the odrl:recipient?).

___________________________________

Joshua Cornejo

marketdata

embed open standards 

across your supply chain

 

Due to the lack of examples (I know Renato), when the standard was originally discussed, I am trying to understand if the common constraints in the rights were discussed, like “Party can execute an action over an Asset if it is part of the Admin Group, but can only execute (some other action) if it is part of the User Group”.