- From: UGent-imec <Beatriz.Esteves@UGent.be>
- Date: Tue, 11 Jun 2024 06:51:38 +0000
- To: Joshua Cornejo <josh@marketdata.md>
- CC: "public-odrl@w3.org Group" <public-odrl@w3.org>
- Message-ID: <DB6PR0902MB2151CF06C10617F75951B46384C72@DB6PR0902MB2151.eurprd09.prod.outlook.>
Indeed, looking at the definitions of the terms might not be the best to understand which left operands work to constrain parties/actions, e.g., you could use odrl:spatial to allow/deny something based on the location of the party. I believe this is something that we have previously discussed in the formalist sub-group but haven’t solved yet. Agreed, when we go deeper, as in your example to constrain departments within a party, I would probably define such a constraint on a profile (or again add it in the Community vocab if we see enough use of it). Best, Beatriz From: Joshua Cornejo <josh@marketdata.md> Date: Monday, 10 June 2024 at 12:29 To: Beatriz Gonçalves Crisóstomo Esteves (UGent-imec) <Beatriz.Esteves@UGent.be> Cc: public-odrl@w3.org Group <public-odrl@w3.org> Subject: Re: constraining parties and leftOperands I just did a simple search for Party – only odrl:recipient is associated to it, it might need updating. I agree odrl:industry fits for the broad use of categories when contracting between parties, but narrowing to ACL - if we had also departments (ex:Marketing part of ex:ExampleParty) – we’re back to ‘better’ odrl:recipient? Rgds, ___________________________________ Joshua Cornejo marketdata<https://www.marketdata.md/> embed open standards across your supply chain From: "Beatriz Gonçalves Crisóstomo Esteves (UGent-imec)" <Beatriz.Esteves@UGent.be> Date: Monday 10 June 2024 at 11:23 To: Joshua Cornejo <josh@marketdata.md> Cc: "public-odrl@w3.org Group" <public-odrl@w3.org> Subject: Re: constraining parties and leftOperands Resent-From: <public-odrl@w3.org> Resent-Date: Mon, 10 Jun 2024 10:23:20 +0000 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@01DABB29.5942BC50] Regards, ___________________________________ Joshua Cornejo marketdata<https://www.marketdata.md/> embed open standards across your supply chain
Attachments
- image/png attachment: image001.png
Received on Tuesday, 11 June 2024 06:51:50 UTC