Re: [poe] ambiguous semantics of duty constraints

I point at my suggested solution in https://github.com/w3c/poe/issues/215#issuecomment-323785168 
and try to harmonise it with @riannella suggestion above:

* a key problem is that the current Duty Class a/ inherits a lot of design and processing rules from the Rule Class and not all the inherited things fit well into the Duty Class uses and b/ the Duty Class specification sets definition which don't harmonise with the different properties of type Duty Class (obligation, duty, consequence, remedy). See the list of usages of Duty Class by properties in my comment.
Suggestions: 
    * we should at least remove generic definitions from the Duty Class if they don't harmonise with the properties and define these details for each property individually
    * a larger step is to remove the Rule Class inheritance by making the Duty Class a stand-alone class.
* Re "fulfilled" and "infringed":
  * by the status design of Renato a Duty Class may have three stati
    * fulfilled: all what is required by a Duty Class instance is ok 
    * not fulfilled: at least one particle of a Duty Class instance is not ok
    * infringed: the first level Duty as such is not ok, the first level Duty has a consequence Duty and this Duty should be performed. 
  * As a consequence Duty exists only for Duty Classes used by a duty property in a Permission "infringed" is not generic. The processing model must be: check first the action and the constraints of the duty Duty. If the result is not ok the check if this duty Duty has consequence(s). If it has none then the result of the duty Duty is "not fulfilled", if it has one to many all of the consequence Duties must be performed. Only if all the consequence Duties return a "fulfilled" status the duty Duty is "fulfilled", else it is "not fulfilled".
  * My text above uses the terminology "... Duty is ok". This is an interim and internal status of a processing model of a Duty and may either be transformed into the formal "fulfilled" or "not fulfilled" or it may trigger the processing of consequences ...
  * ... but by my understanding also the "infringed" status is only an internal status, it will never be delivered as final status of a duty Duty instance. So I see "is not ok" and "infringed" in parallel: "infringed" exists only as "not ok" status for the duty Duty, while a "not ok" status of other kinds of Duty usages in obligation, consequence and remedy has not special name. If we need an internal status after checking the action and the constraints of a Duty Class instance and even if it only for the duty Duty we should have a single name for that - "infringed" is too harsh for that status in all cases, but that's only my personal view.
  * Renato's discussion of "infringed" raises the question: how to deal with violated Prohibitions? The definition of the use of remedy in 2.5.7 of the IM tells a Prohibition may be "violated". I suggest to use the same term for a "not ok duty Duty" and a "Prohibition action which has been taken": infringed, violated ...

My general suggestion: we need strict but this way also easy to follow (and as I hope understand) processing models for the use of a Duty class with each of the different properties and less generic specification in the Duty Class section.


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

Received on Tuesday, 22 August 2017 08:32:20 UTC