Modelling duty/obligation

[fornaran]

In ODRL a “Duty entity indicates a requirement that MUST be SATISFIED for Permissions to become VALID.…Even though a Duty entity is mandatory, the ODRL model does not specify any conditions on WHEN the Duty Action must be performed.”

If I understood the semantics of a Duty correctly, in order to be allowed to use a VALID permission a party must BEFORE satisfy the related Duty; otherwise, the permission is not VALID. In case the party perform an action that is not permitted, the party may/will be sanctioned. Therefore, it is clear that the Duty Action MUST be performed BEFORE to use the permission.

Therefore, in ODRL it is not possible to express policies where the duty (or better the obligation) to perform an action in ACTIVATED AFTER a given permitted action has been already performed.
Examples of this policies are:

• A nurse is permitted to use an “emergency account” for getting access to sensitive health data of a patient, if the emergency account is used the nurse becomes obliged to write a report within 1 week.
• I have the permission to enter in a “limited traffic area” of a big city, after entering in the area I have to obligation to pay x euro within 24 hours.

It is also crucial to inform a user about the new obligations that the performance of a given action will create for him/her.

[riannella]

hi @fornaran - thanks for your feedback.

You say "...in order to be allowed to use a VALID permission a party must BEFORE satisfy the related Duty" - this is not totally correct. There are some use cases where a Duty could be satisfied after the permission has been actioned (eg stream music and pay at the end of the month).

But I think the wording can be made more clearer in Duty section: http://w3c.github.io/poe/model/#duty

I think we update this:

The Permission is valid (including the Permission's constraints all being satisfied) if and only if the Duty has been fulfilled

to:

The Permission is valid (including the Permission's constraints all being satisfied) if and only if the Duty has been or will be fulfilled

Does that sound more clearer?

[fornaran]

Hi riannella - thanks for your answer.
The proposed update allows the semantics of permission with duties to express a wider set of use-cases, but I see a problem.

When do I obtain a VALID permission (and therefore I can use it without violating a prohibition)?

1. If I obtain a VALID permission to perform an action (i.e. play stream music) if and only if the Duty has been fulfilled (i.e. pay 1 euro). This means that if I do not fulfill the duty I will not get a VALID permission. That is the fulfillment of the duty is a pre-condition for getting a valid permission.

2. If I obtain a VALID permission to perform an action (i.e. play stream music) if and only if the Duty will be fulfilled (i.e. pay 1 euro). This means that I get the permission when the policy is attached to the asset regardless the fact that the duty/obligation is satisfied or not. If in the future I will not fulfill the duty/obligation I may be sanctioned for the duty/obligation violation, but in the meantime (thanks to the valid permission) the permitted action may have been already performed.

In my opinion, the semantics of permission can be used to express policies of type 1 (fulfilled duty->valid permission) or policies of type 2 (valid permission->active duty/obligation) but using one construct for covering both types may create a lot of confusion on the semantics of duty-permission.

[riannella]

We will be treating "constraint checking" as a "black-box" for ODRL evaluators (as we are not scoped to address enforcement, only expression).

So when an constraint is evaluated by the external system, it will simply return true or false.
If its true, then the Permission is valid, if false, then not-valid.

So in case 2) above, the implementations may have the assignee's credit card details (which we don't know about) and then is happy to return "true" (and charge them later at the end of the month).

The only real difference between 1) and 2) is temporal.
Ideally, that would be part of the compensate duty (that you can pay at the end of the month), and still get access to the Permission now.

[riannella]

Hi @fornaran Are you ok with this response?

[fornaran]

Hi riannella,
Your response is ok for me for modelling all those cases when a credit card (or something similar) is communicated before to use a given service.
Nevertheless, a policy may also need to express the obligation to perform an action because of the performance of another action. For example if you enter in a Congestion Charge area then consequently you are obliged to pay x euro within 24 hours.
How is it possible to express this type of policies?
Regards

[riannella]

I am not sure this use case fits?

ODRL expresses statements about content usage...so, for example, what asset is the Policy about?

You could (if you wanted) define the "congestion area" as an Asset, then an action "drive-in", then add a Duty (pay x $)

[fornaran]

From my oint of view the Duty (pay x $) is not a pre-condition for performing the action "drive-in" on the asset "congestion area", in fact the access to the congestion area is not prohibited (there is not a barrier).

Like for the nurse example reported in my first comment, the policy that I would like to express is:

A certain action a1 is permitted (i.e. it is permitted to enter a congestion area, the nurse can use the “emergency account”) and I want to express the fact that if action a1 is performed then the actor of the action becomes obliged to do something else (i.e. pay within 24 hours or write a report within 1 week).

From my point of view in ODRL it is possible to express a different type of policy:
A certain action is prohibited (i.e. play stream music) if a certain pre-condition (the duty) is satisfied then the permission to perform the prohibited action is granted.

Regards

[riannella]

Yes, you can create a new Policy Type (like these: http://w3c.github.io/poe/vocab/#policySubClassesCommon)
So, this sounds like it might be better for your use case?

[fornaran]

For being able to model my use cases, I need to be able to express a policy that contains one obligation to perform an action (pay within 24 hours) that is activated when a certain event happens (enter in the congestion area). If a pay within the deadline this obligation becomes fulfilled, otherwise it becomes violated.

Given that in ODRL a Policy is "A non-empty group of Permissions and/or Prohibitions" I cannot simply create a new Policy Type.

[riannella]

We are discussing in #162 an update that a Policy can contain "any Rules".
(including just a Duty)
That change should then meet your requirement?

[fornaran]

A Policy that can contain just a Duty is the first step.
For being able to model my use cases the notion of Duty/Obligation should enriched.

In particular what I miss is the notion of state of the obligation that follows a specific lyfecycle.
Like for the notion of permission there is the idea of having a "valid permission" when the duty is satisfied, and I suppose a "conditioned permission" when the duty is not yet satisfied.

An Obligation may be conditioned, activated, satisfied or violated.

Regards

[riannella]

Perhaps you could model this with a new Rule and Policy type?

The concept of "activated" would need to be supported. That is, upon the "action" being activated, then you must do Duty X.

The current Rules are not pro-active. So, perhaps a new Rule could work (lets says its called "Trigger"). Trigger is an action ("enterArea" even with constraints like "on weekdays"...).
Trigger could then have a Duty that is defined to be meet if the Trigger is activated (hence why it would be best to also have a new Policy type to capture that relationship)

[vroddon]

Perhaps in order to prevent circularities in the evaluation of the policy, the trigger action ("enterArea") should not have other duties imposed --thinking of this as a production rule system.

[simonstey]

@riannella

The concept of "activated" would need to be supported. That is, upon the "action" being activated, then you must do Duty X.

duties on permission level are exactly that, e.g.:

    a odrl:Policy;
    odrl:permission [
        a odrl:Permission ;
        odrl:target  ;
        odrl:action odrl:reproduce ;
        odrl:assigner ex:Bob ;
        odrl:assignee ex:Alice ;
        odrl:duty [
             a odrl:Duty ;
             odrl:action odrl:play ;
             odrl:target  ;
        ]
    ] ;
    odrl:permission [
        a odrl:Permission ;
        odrl:target  ;
        odrl:action odrl:print ;
        odrl:assigner ex:Bob ;
        odrl:assignee ex:Alice ;
    ] .

only if ex:Alice wants the permission to odrl:reproduce the target asset is she obliged to odrl:play the asset . If she only wants to odrl:print it (or simply doesn't care about the asset at all), she isn't obliged to do anything.

[fornaran]

The clear specification of the evolution of the state of permissions, prohibitions, and duties is fundamental for having a clear semantics of the proposed language.

The duty inside a permission is actually a pre-condition for getting the permission. If Alice does not care about the asset, she is not obliged to do something; in our everyday life, we will never say that she has a duty. If she wants to get a VALID permission, she has to do something, i.e. satisfy the duty or better the pre-condition for getting a valid permission.

If the duty/pre-condition is not satisfied, Alice has not a valid permission.

With this semantics, it is hard to express a policy that gives to Alice a valid permission to play a music file and contemporarily obliges Alice to pay 5 euro at the end of the month. This because the payment (that will happen after the creation of a valid permission) cannot be formalized as a pre-condition/duty. In fact, the payment is not a pre-condition; differently, we need to formalize an obligation to pay 5 euro at the end of the month, and this obligation becomes active when Alice get a valid permission to play a music file.

This type of obligation can also be used to formalize the congestion area. It is an obligation to pay with in 24 hour that is activated when I enter with my car in the congestion area. Obviously, the action that activates the obligation (play music file, or enter congestion area, getting a valid permission) should be possible otherwise the obligation will never become active.

I agree with riannella, it is possible to model those use cases (stream music with later payment, congestion area, nurse in the hospital) by introducing a new Rule called obligation with its own lifecycle. In principle, this new Rule can be used in the already existing Policy Types.

[riannella]

Inspired by: https://www.w3.org/community/odrl/model/2.1/#section-53

If we supported Duties for Prohibitions, then you could say "you are prohibited from driving in the congested area". If you do, then you have a Duty to pay x$.

[fornaran]

It seems to me that is counterintuitive modelling
an obligation to perform an action when an activation condition is satistfied (entered in the congested are then obliged to pay)

by using
a prohibition to perform an action (entering in the congested area) and a duty that must be satisfied when the prohibition is violated (pay).

Moreover if the fulfillment or violation of obligations and prohibitions are connected to the reputation of their assignee agent this formalization may bring to a wrong computation of the assignee's reputation value.

[riannella]

@fornaran
I assume there is no change you are now proposing for the IM or Vocab?
Can this issue be closed now?

[simonstey]

@riannella

I assume there is no change you are now proposing for the IM or Vocab?

well, she agreed to your proposal:

I agree with riannella, it is possible to model those use cases (stream music with later payment, congestion area, nurse in the hospital) by introducing a new Rule called obligation with its own lifecycle. In principle, this new Rule can be used in the already existing Policy Types.

and I actually like the idea of having "Obligation" as new type of rule, i.e. differentiating between policy/permission-level duties, as it would help addressing a lot of issues/inconsistencies of the current IM, such as:

1. Constraints on permissions/prohibitions behave differently than constraints on duties
   • Constraints on Perm/Proh:

     For a Rule, if the Constraint is satisfied then the action becomes effective for the enclosing Rule.

   • Constraints on Duties:

     Such business rules MAY be expressed through additional Constraints. For example, a Policy may state that you can play a music file for a payment of $5.00.

2. @riannella: "Policies need to have consistent Rules processing." (Model clarifications #162 (comment))
3. @riannella: "My concern is that I don't want the semantics of Duty to change depending on where it is in the Policy." (Model clarifications #162 (comment))

---

Proposal:

1. Add Obligation as new subclass of Rule (alongside Perm/Proh/Duty)
2. Allow only Perm/Proh/Obligation on policy-level
3. Allow only Duties on permission-level
4. Constraints on Obligations have the same semantics as the ones on Perm/Proh.

tbd: how to handle constraints that specify how an action must be performed.

[riannella]

Actually, what I meant was that such an extension is possible - so @fornaran's Profile could do that - not that we (the WG) would add it.

[riannella]

What is the difference between an Obligation and a Duty ?
(Given that a Duty is "The obligation to perform an Action")

[fornaran]

I agree with @simonstey that adding Obligation as subclass of Rule would be a perfect solution. I am also working on a paper with a proposal that goes in this direction I hope it can be formalized as an ODRL Profile.

From my point of view a duty connected to a permission is actually a precondition, it is not an obligation. An agent can decide to satify a "duty" if she wants to get a valid permission but she can also never satify it.
An agent with active obligation must satisfy it otherwise she gets a sanction.

Thank you very much for this discussion it was very fruitful for me.
I agree with @riannella that this issue can be closed.

Kind regards.

[riannella]

(we can't close the issue until we resolve and address it ;-)

I think then that the issue is not the class Duty, but the property "has duty".

A Duty, as defined as "The obligation to perform an Action" is fine as is.

The "Has duty" property is defined as "The duty relating to the Permission", but really should be more specific (as we have used it in the past) as "A Duty that is a precondition for a Permission" (or something along those lines...)

And we have a new property "Has Obligation" defined as "A Duty that must be fulfilled".

"Has Duty" is for Permission->Duty relationships.
"Has Obligation" is for Policy->Duty relationships.

[riannella]

Updated the IM/Vocab to now support the obligation property for policy-level Duties.

commit: 36d1a6a