Harmonise how a Duty with consequences should be evaluated

[nitmws]

This is about the CR version of the IM, today (25 September) at https://w3c.github.io/poe/model

The Duty Class definition says about consequences:

If its (= the Duty's) action has not been exercised, then all consequences must be fulfilled to fulfil the Duty.

Further down in this section the description of the consequence property says:

If either of these (= a duty or obligation) fails to be fulfilled, then this will result in the consequence Duty also becoming a new requirement, meaning that the original obligation or duty, as well as the consequence Duty must all be fulfilled.

These two statements are not aligned: the first one does not require to exercise the action of the Duty, the second one does.
I suggest - as minimal approach, see more below - to change the 1st paragraph of the Duty Class to:

A Duty is the obligation to exercise an action, with all refinements satisfied. A Duty is fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been exercised. If its action has not been exercised, then this action has to be exercised and all consequences must be fulfilled to fulfil the Duty. (Note: only Duties referenced by duty or obligation properties may use consequence properties.)

This wording above defines in fact but not explicitly the need to run two evaluations of the same Duty instances:

• Round 1: the Evaluator detects the action of the Duty has not been exercised
  This triggers:
• Round 2: the Evaluator has to check if the action of the Duty has been exercised AND if all consequences of the Duty have been fulfilled. Only in this case the evaluated Duty can be set to Fulfilled.
  (This should be reflected in the Truth Tables of the Evaluator page.)

To make this transparent it would help to integrate such a 2-rounds-evaluation in the definition. My suggestion, round 2 ;-)

A Duty is the obligation to exercise an action, with all refinements satisfied. A Duty is fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been exercised. If its action has not been exercised, then the Duty has to be evaluated again requiring that its action has been exercised and all consequences have been fulfilled to fulfil the Duty. (Note: only Duties referenced by duty or obligation properties may use consequence properties.)

[riannella]

Hi @nitmws - can we turn this into two issues? One for the testing phase, and one as formal CR Review editorial feedback? (and they will be addressed separately)

[simonstey]

Round 2: the Evaluator has to check if the action of the Duty has been exercised AND if all consequences of the Duty have been fulfilled. Only in this case the evaluated Duty can be set to Fulfilled.

and what happens after round 2?

[nitmws]

Re @riannella : this issue should be considered first in the test phase of course. If we agree on the approach we will make it a formal CR Review feedback? I'm ok with that.

[nitmws]

Re @simonstey

The ODRL Processor having evaluated the Duty has to draw its conclusions from the Duty's state Fulfilled or Not-Fulfilled. E.g. if the Duty is a duty of a Permission and the result is Not-Fulfilled then the Permission's state cannot be Allowed anymore. This applies also to Duties referenced by consequence or remedy; for an obligation-Duty the Processor returns the state to the system which has requested to evaluate the obligation.

[simonstey]

E.g. if the Duty is a duty of a Permission and the result is Not-Fulfilled then the Permission's state cannot be Allowed anymore.

"cannot be Allowed anymore" as in never ever or until it's evaluated again?

[nitmws]

This happens inside the evaluation of a Permission, step by step:

• the IM requires for setting a Permission to Allowed that all existing duties have to be Fulfilled
• the evaluator has to iterate over all existing duties ...
• ... and if only a single one returns Not-Fulfilled the condition for setting the state of the Permission to Allowed is not met.

[riannella]

I think there is a simple editorial solution. Simply add "also" to "...then all consequences must also be fulfilled..."

The latter paragraph about consequence, makes it clear that is is an additional Duty (so current implementors must support that).

See #275 for more comments...

[nitmws]

Sorry, I disagree. In #275 @simonstey demonstrates that if the "original Duty" has a temporal constraint this Duty cannot be fulfilled outside the time set by the temporal constraint, by the logic of constraints this is impossible.

Therefore:
The paragraph about the consequence property should be changed to (and a typo in the second sentence should be fixed):

If either of these fails to be fulfilled, then this will result in the consequence Duty/ies becoming a new requirement, meaning that all the consequence Duty must be fulfilled. For example, if an obligation to provide data by a certain date is not fulfilled, then a consequence of a $100 fine is payable as well.

We may add as Note:

Note: if a not-fulfilled Duty having consequences should be fulfilled too when evaluating the consequences it should be expressed as one of the consequences.

The first paragraph in 2.6.6 Consequence property with a Permission/Obligation Duty should be changed to:

A duty of a Permission, and obligation of a Policy, may include a consequence Duty of not fulfilling that duty or obligation. In this case, all consequence Duties must be fulfilled to set the final state of the Permission/Obligation Duty to fulfilled.

[riannella]

I understands where the issue is - but the ODRL IM does not define any temporal constraints, only that the duty is satisfied or not. From a machine perspective this may be difficult with a hard-coded date. From a business perspective, it does work (ie you can still pay a bill after the due date in most companies ;-)

So the IM, i think, is correct in the scope of the normative statements.

As an example, the GDPR may say you have 60 days to remove my personal data, otherwise you are fined $EU10,000. After 61 days I pay the fine, but I don't remove the personal data since the 60 days has passed. This is not the intention of the consequence.

[riannella]

So perhaps the editorial note should say:

Note: Having triggered a consequence, a non-fulfilled duty must also be fulfilled by ignoring the constraints that triggered the non-fulfilment of the duty.

[nitmws]

Now things get complex as we reuse the same examples and associated assumptions too much:

• That an "original Duty" can be exercised after not having been exercised is not guaranteed. This is an assumption without any proof as the POE WG does not know what duty-actions will be defined by profiles beyond the Common Vocabulary - and ODRL should not build on assumptions.
  (Quick aside: a Policy could reflect a road traffic law, not only GDPR, one Obligation is: "do not crash the car into another one". And the consequence is: "the insurance data of the car causing the crash must be shared with the owner of the other car to get it repaired". In this case the original Duty "not to crash into another car" cannot be fulfilled, the damaged car can only be repaired.)
• Further: why do we assume that all users of ODRL must have the requirement that the "original Duty" MUST be fulfilled in the context of consequences? I know from public transport systems that if you use it without a ticket you have to pay a fine - and this includes getting a valid ticket. Such a solution must be possible for a user of ODRL!
• re @riannella "I understand ..." above: which "IM" is correct: the definition of the Duty Class or the explanation of the consequence property?
  And we have to be very careful: there is a fundamental difference between what must be fulfilled by the definition of the ODRL IM (as this is hardwired, no escape from it) and what must be fulfilled as one of the consequence Duties (as this is flexible, has to be defined by the maker of the Rule.)
  I hope it can be understood that I'm against hardwiring assumptions - see above.
• re @riannella 's note above: it is another assumption that only constraints are the reason for the problems with fulfilling the "original Duty". It could also be a specific action only.
• Why don't we pick the simple solution which is also very flexible: if the "original Duty" should be fulfilled in the context of consequences then it should be explicitly expressed as one of the consequence Duties - maybe with less constraints.

[riannella]

@nitmws my response has been based on the current IM narrative that states that the original duty MUST also be satisfied if it triggers the consequence duty.

I have asked @simonstey and @sabrina to verify/clarify that is the correct interpretation (as the consequence duty was introduced based on their requirements) #275

If it turns out to be true, then we need to address the satisfaction issue of the original duty.
If it does not, then we need to update the IM (and this is a non-editorial change)

[nitmws]

@riannella @simonstey and @sabrina let's have a look back at square 1 of this Issue:

In the current IM we have this definition right under the heading 2.6.3 Duty Class - without any word about a requirement to fulfil of the "original Duty" to finally fulfil the Duty with consequences.

A Duty is the obligation to exercise an action, with all refinements satisfied. A Duty is fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been exercised. If its action has not been exercised, then all consequences must be fulfilled to fulfil the Duty.

And we have in the current IM this language as narrative regarding the consequence property (defined some paragraphs above that) - raising the requirement to fulfil both the "orginal Duty" and the consequences.

The consequence property (a sub-property of the failure property) is utilised to express the repercussions of not fulfilling an agreed Policy obligation or duty for a Permission. If either of these fails to be fulfilled, then this will result in the consequence Duty also becoming a new requirement, meaning that the original obligation or duty, as well as the consequence Duty must all be fulfilled.

Status of the issue at this point: the current IM has contradicting definitions - one of them must be selected for a final ODRL Recommendation. At the formal level of the CR none of these definitions has an explicit precedence.

Next comes Issue #275: @simonstey demonstrates that it is possible to define an "original Duty" which is impossible to be fulfilled when a Duty is evaluated under the requirement to include the consequences.
And the Note suggested by Renato three comments above would explicitly change the IM: constraints have to be ignored!

Status of the issue at this point: if the POE WG would select the consequence definition "original Duty and consequences must be fulfilled" the result would open the door for Duties which cannot be processed successfully - and this should be avoided with regards to the quality of ODRL.
And to clarify: for me it is questionable if such a bad state could be considered as satisfying Simon's and Sabrina's requirement.

To get out of this situation I suggest (again):

1. Stick to the definition of the Duty Class, right under the 2.6.3 heading and ...
2. ... adjust the consequence definition to it this way:
   The consequence property (a sub-property of the failure property) is utilised to express the repercussions of not fulfilling an agreed Policy obligation or duty for a Permission. If either of these fails to be fulfilled, then this will result in the consequence Duty/ies becoming a new requirement, meaning that all the consequence Duties MUST all be fulfilled. If a business need requires to fulfil also the original obligation or duty then it must be expressed as a consequence.

This solution would satisfy the requirement raised by Simon and Sabrina - it is possible to define "also the original Duty must be fulfilled" -, it avoids running into dead-end streets when processing a Duty, and the IM would not be changed, the definition at the top of 2.6.3 takes some precedence and the features of the consequence are reformulated.

[simonstey]

If a business need requires to fulfil also the original obligation or duty then it must be expressed as a consequence.

related to that, what was the reason for requiring that ->

Note that the consequence property MUST NOT be used on a Duty that is already a consequence for a Permission duty or Policy obligation.

avoiding cyclic dependencies?

[nitmws]

As I recall from the discussion at a call it was avoiding infinitely nested consequences, and that makes sense. (We at IPTC had such nested structures and implementers told us: "this does now work in a reliable way in practice". Since then we avoid that.)
Further this excludes cyclic dependencies as a Duty having consequences cannot be reused as one of its consequences.

To clarify this regarding my suggest wording of the consequence definition above: the re-expression of the "original Duty" as a consequence may require a few modifications: a) should the constraints be applied (again) (see #275), b) no consequences. See an example of that in #275 (comment)

[riannella]

@nitmws I think we did miss the word "also" in the first para of 2.6.3 Duty Class.
But we do - more formally - define the consequence property in Para 5.

Perhaps what is needed is another failure sub-property?

[nitmws]

@riannella adding "also" to the first para does not help as #275 shows. Based on that issue ODRL MUST sort out a Duty (including constraints and refinements) which must be fulfilled in a first round of evaluation and a Duty with maybe less constraints etc in a second round of evaluation which checks all the consequences - and this modified Duty should be made one of the consequences. This does not change the IM, only how to deal with a specific business need - include the original Duty in the second round - is modified but the feature as such is left untouched.

Re another failure sub-property: the ODRL WG must not change the IM anymore, inventing new things would go in this direction. And what should be the semantics of such a property - and how should it solve the problem?

[iherman]

Resolution taken at the meeting of the group 2017-10-09: http://www.w3.org/2017/10/09-poe-irc#T13-43-24

[riannella]

Updated the IM. Included a "note" about relaxing the constraints.
Also updated note in the Vocab with same text.

[riannella]

from @nitmws
Hi Renato,
I had a look at the updated language of the Duty Class (2.6.3) definition in the IM version of 10 October (today).

The first paragraph says:
A Duty is the obligation to exercise an action, with all refinements satisfied. A Duty is fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been exercised. If its action has not been exercised, then all consequences must also be fulfilled to fulfil the Duty. That is, the consequence is an additional Duty that must also be fulfilled.

Error: the consequence property may refer “one, one or many” Duty instances, therefore the singular in “the consequence is an additional Duty” is wrong.
Editorial: the fulfil in violet above should be in bold to signal the final state of the Duty Rule.

The explanation of the consequence property in this section says:
The consequence property (a sub-property of the failure property) is utilised to express the repercussions of not fulfilling an agreed Policy obligation or duty for a Permission. If either of these fails to be fulfilled, then this will result in the consequence Duty also becoming a new requirement, meaning that the original obligation or duty, as well as the consequence Duty MUST all be fulfilled.

Error: same as above: the consequence property may refer to more than 1 Duties but the definition uses singulars only.

Re NOTE: the language of this note builds on the assumption that the cannot-be-fulfilled state comes only from constraints.
That’s wrong as constraints are only a flexible narrowing down of the semantics of an action - if they refer to an action – and a duty action with these narrower semantics can be defined without any constraint.

Example: many video makers contract streaming services to publish their videos – and expect a 24/7 service.
A realistic contract is: the video must be accessible 99% of the time of a calendar day, else the video service will be “fined”.
This could be expressed as obligation:
action: “make video accessible 99% of the time of a calendar day”
constraint: none
consequence - action: pay back 50% of the service fee for 1 day
Use case: the missing 1% is about 15 minutes – but the video has not been accessible for 20 minutes already at 14:00 -> obligation Duty state: not fulfilled.
How can such an obligation Duty ever be fulfilled? For the remaining 10 hours of the day definitely not. And ignoring constraints does not help because there is none.

Second issue with this NOTE re “In such cases, ODRL implementations SHOULD provide mechanisms to allow the original duty to be satisfiable.”
The implementation of what: of the Policy/Rule sent out to customers/clients OR of the customers/clients receiving the Policy/Rule? OR both?
As ODRL is made to exchange a Policy with Rules between its maker and many receivers the big requirement is: how is this mechanism communicated between the maker and the receivers? Outside of ODRL Policies, inside ODRL Policies?

[riannella]

Updated the plurality of consequences.

We don't define how Policies are exchanged (only expressed) and we still have the "black-box" notion of evaluation of constraints.