Re: constraining parties and leftOperands

Hi,
Not that I have anything against adding `role` as a left operand (we can even do it here https://github.com/w3c/odrl/issues/43), but I think what you want to achieve can be done with something like

# constraint that user is an administrator
odrl:recipient odrl:eq ex:Administrator;

# constraint that the user is in Media and an Editor
odrl:recipient odrl:eq ex: Editor;
odrl:industry odrl:eq ex:Media;

Best,
Beatriz

From: Joshua Cornejo <josh@marketdata.md>
Date: Sunday, 9 June 2024 at 19:52
To: public-odrl@w3.org Group <public-odrl@w3.org>
Subject: constraining parties and leftOperands
Hello,

In advance - forgive the output of the diagram – plantuml offers little control over the layout.

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”.

In today’s odrl:LeftOperand, odrl:recipient is the only one that involves the Party/PartyCollection. And I know I could extend it or add more functions – but this being so basic and common, more enquiring about the current interpretation.

If it was, how would examples like the following be implemented from the Party perspective:

# constraint that user is an administrator
odrl:recipient odrl:eq ex:Administrator;

# constraint that the user is in Media and an Editor
odrl:recipient odrl:isAllOf ex:Media, ex:Editor;


I tried to model it as follows, but I am conscious of traversing “part of” relationships vs subclasses.

Ignore UML conventions as limited by PlantUML:
(A – abstract)
(C – tangible categories)
(I – instances)

[cid:image001.png@01DABA9E.1D5E7660]


Regards,

___________________________________
Joshua Cornejo
marketdata<https://www.marketdata.md/>
embed open standards
across your supply chain