- From: simon via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Jun 2017 06:05:38 +0000
- To: public-poe-archives@w3.org
> So why then can't Bob and Alice have an odrl:Agreement to pay 10€ ? (that make more semantic sense ;-) it does, but Agreements have to have at least one Perm/Prohib. What would be the accompanying Permission? The use of those 10€? ;) > What if you inherit a Set (with just a Duty in it) into an Agreement? The same as if you inherit an Offer (having Rules with assigners only) into an Agreement, the Agreement would become invalid. (assuming inherit A into B means B inherits from A) > Policies need to have consistent Rules processing. I agree! But since we treat duties as black boxes anyway, we only have to know whether: + a duty is in effect -> it's in effect as long as it wasn't fulfilled + a policy is in effect -> it's in effect as long as at least one of its rules is in effect > Perhaps we ~~only~~ allow Duties at the Policy level (like Perm/Prohibit) and it simply means that all the Duties need to be satisfied for all the Perms/~~Prohits~~ in the Policy to be "in effect" ?? sounds great!! I would suggest though to: 1. keep the current cardinality restrictions on policy types as is 2. allow top-level duties for Offer/Agreement only, if there's at least one permission in the policy the duties can be assigned to 3. still allow to define duties for permissions directly 4. at some point we may want to consider allowing duties to "switch **off**" prohibitions if they are fulfilled, but never to switch them **on** (you wouldn't pay 10 euro to be prohibited to do something). 5. (nitpicking) you **satisfy** a constraint, but **fulfill** a duty -- GitHub Notification of comment by simonstey Please view or discuss this issue at https://github.com/w3c/poe/issues/162#issuecomment-310284584 using your GitHub account
Received on Thursday, 22 June 2017 06:05:45 UTC