Re: [poe] Reviews of ODRL IM - Editor's Draft 3 August 2017

Follow up after the POE call on 21 August and reading the parts about Duty in #211 and the issue about modelling Duty/obligation #191: 
* I got at the call that an obligation Duty is a different kind of Duty compared to a duty Duty: it has no impact on a permission ...
* ... but I raise: this needs an explicit definition of this "other kind of Duty", currently we only have use cases outlining this other use:
  * At this call Sabrina said: the obligations of a Policy define what needs to be fulfilled to claim the Policy is fulfilled and this could make an action legal. And she pointed at regulations like the GDPR (http://www.eugdpr.org), they could be expressed this way. 
In my words: obligations of a Policy define what needs to be done to meet a regulation being the target Asset of the obligations. But this is only a guideline, not a rule.
  * ... and @simonstey  said: if he and Sabrina agree that he pays Sabrina 5 EUR this could be expressed by an obligation Duty.
In my words: this is a documentation of an agreement, fulfilling or not fulfilling this obligation has no role in the Policy.

Considerations:
* The Duty Class is defined as "A Duty is the obligation to perform an Action." It claims that "agreed actions must be fulfilled" but a/ what is an _agreed_ action and b/ what does it mean to fulfil an action - the IM uses _fulfilled_ primarily as the result of a Duty Class instance.
* Let's have a look at how the Duty Class is used by different properties:
  * In a Permission a fulfilled duty is required to put it "in effect" = the duty has a strong role in the scope of the Permission.
  * In a Prohibition a remedy is an action which must be taken if the Prohibition has been violated = this is a follow up of taking the action of violating the Prohibition. If the remedy has been fulfilled or not is outside the scope of the Prohibition.
  * In a Duty a consequence is an action which must be taken if the duty has not been fulfilled and the action of the parenting Permission has been taken = this is a follow up of taking the Permission-action without the fulfilled duty. If the consequence has been fulfilled or not is outside the scope of the Permission.
  * In a Policy a obligation is "the obligation to perform an Action". Currently the IM does not define any context for that. So the ODRL user does not know if fulfilling an obligation or not has any kind of resulting impact (an obligation must not use consequence or remedy!).
* In #191 @riannella  raises the question "What is the difference between an Obligation and a Duty ?" 
My answer: currently only the structure of the Class is common, the reasons for executing "the obligation to perform an Action" are quite different and also the use of the result status of "the Action has (not) been executed successfully" is quite different.
* **A solution for that could be**:
* A basic action is: make the Class a standalone class and not a sub-class of Rule. This way we would get rid of all what's inherited from the Rule Class.
* Second: re-define the Class:
  * name: Required Action Class (to move the name of the class far away from properties using it, the use of Duty and duty in documents about ODRL is confusing.)
  * definition: A Required Action is the obligation to perform an Action. The Required Action is to be considered as taken if all constraints have been satisfied and if the action of this class has been performed.
  * properties: 
    * MUST have one action property value of type Action
    * MAY have none or one target property values (of type Asset) to indicate the Asset that is the primary subject to which the Required Action directly relates. (Other relation sub-properties MAY be used.)
    * MAY have none or one assigner and/or assignee property values (of type Party) as functional roles. (Other function sub-properties MAY be used.)
    * MAY have none, one or many constraint property values of type Constraint/LogicalConstraint.
    * MAY have none or one uid property values (of type IRI [rfc3987]) to identify the Required Action so it MAY be referenced by other Required Actions or Rules.
    * MAY have none, one or many consequence property values of type Required Action if used with the property permission.
    * MAY have none, one or many remedy property values of type Required Action if used with the property prohibition.
* Third option: each property of type Required Action Class must define how it is used = what an impact "the Required Action (not) been taken" has on the context of this property.

<hr>

Footnote on this issue raised at the call: "the constraint defining the amount to be paid" and "the constraint when the payment has to be made" are different. Sorry, but I can't see a significant difference between these constraints. Maybe we have to create sub-Actions of "compensate": pre-compensate if a time constraint has to be satisfied prior to performing the permitted action or post-compensate if the time constraint can be satisfied after the permitted action has been performed. But this is more an issue of well defined actions and constraints and not an IM design issue.

-- 
GitHub Notification of comment by nitmws
Please view or discuss this issue at https://github.com/w3c/poe/issues/215#issuecomment-323785168 using your GitHub account

Received on Monday, 21 August 2017 16:04:22 UTC