Re: [poe] ambiguous semantics of duty constraints

re @riannella 

re 1: I may have to clarify: I think that the properties obligation, duty, consequence and remedy don't make use of the Duty Class in the same way. This not about the properties of the Duty or the Rule Class.
* duty: the "original" property. If it is in effect processing it must return a fulfilled/not-fulfilled status. While being processed it may have an infringed/violated internal status. The statuses of a duty have an impact on the permission Rule including it.
* consequence: same as duty regarding "(not) in effect" and the returned  status. Both have an impact on the duty Duty including it. It may have an internal infringed/violated status but this has no impact on anything. 
And: a consequence Duty must not have a consequence property.
* remedy: same as duty regarding "(not) in effect" and the returned status. Both have an impact on the prohibition Rule including it. Same as consequence regarding infringed/violated.
And: a remedy Duty must not have a consequence property.
* obligation: same as duty regarding "(not) in effect". A generated fulfilled/not-fulfilled status has no pre-defined impact on anything inside the Policy including obligation(s). (I guess this could be a use case: Policy 01 includes obligation(s) and a Permission (of another Policy ?) has this duty "all obligations of Policy 01 must be fulfilled"). An obligation may have an internal infringed/violated status but this has no impact on anything. 
And: does a target property make sense for an obligation?

Conclusion: 
* the use of the consequence property depends on the property of type Duty. A strict design would have a basic Class without a consequence property for the consequence and remedy properties plus a sub-class with consequence property for duty and obligation.
* The handling of an internal infringed/violated status is inconsistent for the different properties of type Duty.

re 2: I had a deeper look at the table - and suggest to rename it to rule-processing-statuses to clarify its message
* we should make readers aware that more than 1 constraints, duties, consequences or remedies may be in a Permission - and that they are ANDed.
* re "infringed": it is a surprised to see "infringed" as status of Permission. So far we have discussed only to name the processing result "the evaluation of taking the action and of the constraints of a Duty is not ok" as "infringed". And this is Duty-internal only: if there is no consequence this results in a "not fulfilled" Duty status, if there is a consequence it must be processed.
* Duty row(s):
  * I think a row intentionally without a status in the "action" column doesn't make sense. Or is only the "Not-Exercised" missing? 
  * For a full coverage of stati the case Infringed/Satisfied/ / Fulfilled/ /Not-Exercised/Not-Fulfilled should be included.
  * (I omit comments on Permission and Prohibition here, but see re 3 below)

Conclusion: such a table should be included into the IM - we need a clear and detailed processing model.

re 3: I recall the question "what happens in case of violated prohibitions without a remedy" was raised at a call. The response was "nothing, if something should happen the assigner has to define a remedy".
* To simplify things I suggest to have only the status "violated": if a Prohibition has no remedy this is the final status of the rule, if there is a remedy it has to be fulfilled: if it has been fulfilled the final status of the Prohibition is "ok", if not the status is still "violated".
* what does "(Not-)Confirmed" mean? By my understanding the term "confirm(ing)" implies taking an action but ODRL raises not need to tell the assigner "we confirm the prohibition Prohib997". Maybe "(Not-)Accepted" is a better term, or "(Not-)Complying-With"



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

Received on Wednesday, 23 August 2017 08:13:42 UTC