- From: Michael Steidl via GitHub <sysbot+gh@w3.org>
- Date: Sat, 12 Aug 2017 18:18:45 +0000
- To: public-poe-archives@w3.org
@vroddon I have a slightly different, maybe more real world business driven view on that: * Prohibition tells that an action must not be taken * If the action is taken despite of this prohibition there are two options * a fine (remedy) action must be executed - users will take this prohibition seriously * no fine/remedy applies to this violation of the prohibition - users will consider such a prohibition as a moral guideline In my many years as managing director almost every prohibition in a contract was either bound to a fine/remedy (the contract is terminated, my company will be sued, my company has to pay an already defined fee, etc.) or nothing like a fine/remedy was bound to it - and in such cases usually a term like _should not_ was used, not a strict _must not._ This was a clear message: the first prohibition was an explicit "you must not take this action" else expect a punishment while the other option was more a moral "we don't like that you do that", a guideline. And for me the practical human background is clear: if one explicitly prohibits an action and does not bind a fine/remedy to it then most of the users will not really care about the prohibition. (I guess this human behaviour is the reason for the existence of fines at all, else a law defining only "don't steal assets of other persons" would be sufficient.) By my understanding the ODRL Prohibition is an explicit "you must not take this action" and I guess many users of ODRL will bind a Policy using prohibitions to their general terms and conditions telling what will happen if rules of a contract are infringed. Btw, this another option of applying a remedy: not an explicit one but an implicit one based on the generic rules expressed by a dc:coverage property. -- GitHub Notification of comment by nitmws Please view or discuss this issue at https://github.com/w3c/poe/issues/215#issuecomment-321997460 using your GitHub account
Received on Saturday, 12 August 2017 18:18:46 UTC