Unsatisfiable consequence example

[simonstey]

http://w3c..io/poe/model/#duty:

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

O1: original obligation or duty
O2: consequence Duty

O2 is triggered once O1 is considered to be not fulfilled and as a result both O1 and O2 have to be fulfilled.

For example, if an obligation to provide data by a certain date is not fulfilled, the a consequence of a $100 fine is payable as well.

O1: provide data by a certain date (e.g., 2017-12-31)
O2: pay 100$ fine

O2 is triggered once O1 is considered to be not fulfilled (i.e., date >= 2018-01-01), now O1 and O2 both have to be fulfilled.
However, without updating O1's refinement constraints that's no longer possible, because in 2018 the obligation to provide data by 2017-12-31 can't be fulfilled anymore.

[nitmws]

This issue is also covered by #267
The problem in the background is: the current definition of when consequences have to be executed and only their fulfilment has an impact on the state of the Duty (in https://w3c..io/poe/model/#duty) . But a description of the consequence property further down in this section raises the need for an also fulfilled original Duty. At the call on 25 September it was requested to make this "both must be fulfilled" the standard.

I suggest the WG considers what would go wrong if we stick to the approach of the top definition of Duty: fulfilled consequences are sufficient to set the Duty state to fulfilled, the action of the main Duty has not impact on that anymore.
(My more business oriented view: after not having exercised the action of the main Duty, the consequences must be fulfilled. This sounds like a common business rule. But having to exercise the action of the main Duty AND having to fulfil the consequences will be overarching for assignees.)

[riannella]

Again, I think an editorial update can address this...

We need to add narrative that for a duty that must also be satisfied - due to the triggering of consequence - that some constraints may need to be relaxed in order for it to be correctly satisfied (and give an example of the temporal constraint).

As for the issue of a consequence being an additional Duty to be satisfied, I think this is the correct model. If it is not, then what you are offering is a selection of duties to choose from, and you can do that more correctly by two rules, one for each Duty.

A typical business case may be to pay $10 by a date, with a consequence of an extra 10% fee if not paid by that date - but both are needed to be fulfilled.

[nitmws]

Pondering which kinds of constraint can trigger such a "cannot be fulfilled" status of a Duty resulted in: "original Duties" (to use the term of the IM) with a temporal constraint cause this problem. But this cannot be solved by narrative only, an evaluator has to check consequences strictly and if the payment has not been exercised inside the time frame set by the constraint it is impossible to fulfil the "original Duty", sorry we cannot put logic upside down.

How to solve the problem outlined above by @riannella:

• the duty of a permission has an action to pay $10 and a constraint to pay before the 1 January 2018.
• if the action should be taken on 6 January 2018 and the $10 have not been paid the consequences are triggered:
  • consequence 1: pay the $10, but without a temporal constraint
  • consequence 2: pay the addition 10% = $1, also without a temporal constraint
    (Ok: the consequences could be merged into a single payment of $11 ...)

This permission in JSON-LD (... using examples 23 and 20):

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:66",
    "profile": "http://example.com/odrl:profile:09",
    "permission": [{
        "target": "http://example.com/data:77",
        "assigner": "http://example.com/org:99",
        "assignee": "http://example.com/person:88",
        "action": "distribute",
        "duty": [{
          "action": [{
              "rdf:value": {
                "@id": "odrl:compensate"
              },
              "refinement": [
                {
                  "leftOperand": "payAmount",
                  "operator": "eq",
                  "rightOperand": "10.00",
                  "unit": "http://dbpedia.org/resource/AUD"
                }]
            }],
            "constraint": [{
               "leftOperand": "dateTime",
               "operator": "lt",
               "rightOperand": "2018-01-01"
           }],
            "compensatedParty": "http://australia.gov.au/",
            "consequence": [{
              "action": [{
                  "rdf:value": {
                    "@id": "odrl:compensate"
                  },
                  "refinement": [
                    {
                      "leftOperand": "payAmount",
                      "operator": "eq",
                      "rightOperand": "10.00",
                      "unit": "http://dbpedia.org/resource/AUD"
                    }]
                }],
                "compensatedParty": "http://australia.gov.au/"
              },{
              "action": [{
                  "rdf:value": {
                    "@id": "odrl:compensate"
                  },
                  "refinement": [
                    {
                      "leftOperand": "payAmount",
                      "operator": "eq",
                      "rightOperand": "1.00",
                      "unit": "http://dbpedia.org/resource/AUD"
                    }]
                }],
                "compensatedParty": "http://australia.gov.au/"
            }]
        }]
    }]
}

[nitmws]

I've suggested minor corrections of the IM in #267 (comment)

[riannella]

@simonstey Are you saying that an unsatisfied duty (that has triggered a consequence) now MUST not ever be satisfied, only the consequence?

Is that a changed requirement from the proposal to support regulations like GDPR?
(which is why we added consequence in the first place)

[riannella]

see proposal in #267

[simonstey]

@simonstey Are you saying that an unsatisfied duty (that has triggered a consequence) now MUST not ever be satisfied, only the consequence?

no.. I'm not saying that the concept of consequence is flawed per se, but that there's some additional narrative required to explain how cases in which consequences are explicitly triggered need to be handled.

E.g., Example 23 is perfectly fine as one can still attribute, even if the consequence was triggered.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:66",
    "profile": "http://example.com/odrl:profile:09",
    "permission": [{
        "target": "http://example.com/data:77",
        "assigner": "http://example.com/org:99",
        "assignee": "http://example.com/person:88",
        "action": "distribute",
        "duty": [{
            "action": "attribute",
            "attributedParty": "http://australia.gov.au/",
            "consequence": [{
               "action": "acceptTracking",
               "trackingParty": "http://example.com/dept:100"
            }]
        }]
    }]
}

[riannella]

Ok, thanks for the clarification.

I believe that we can work on an updated narrative to address this

[riannella]

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