Permissions when a Duty is triggered

[joshcornejo]

Part A

How to represent "asset X can be played 5 times every time duty Y is fulfilled"

• Permission A - has a counter (start 0) constraint count lt 5 with a "duty" triggered pointing at Duty B Duty B

• count eventually reaches 5

• Duty B has no mechanism to indicate "reset permission A"

Part B

• There is no mechanism within the relationship to a Duty to indicate it has been fulfilled ("status" is a property of the constraint entity) on each increase of "count".
• The mechanism should be in the relationship "Permission -[duty fulfilled: true|false] -> Duty", as the Duty could be referenced by multiple Rules within the policy.

[simonstey]

Part B

• There is no mechanism within the relationship to a Duty to indicate it has been fulfilled ("status" is a property of the constraint entity) on each increase of "count".

• The mechanism should be in the relationship "Permission -[duty fulfilled: true|false] -> Duty", as the Duty could be referenced by multiple Rules within the policy.

in https://www.w3.org/TR/odrl-model/#duty it says:

2.6.3 Duty Class

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.

so at any point in time and given the current state of the world, it's up to the ODRL implementations to figure out if:

• all constraints of a duty are satisfied
• its action, with all refinements satisfied, has been exercised.

[joshcornejo]

@simonstey Yes, that is the interpretation of how you consider/evaluate a duty "fulfilled".

As I explain: the same Duty can be a odrl:duty / odrl:remedy or odrl:consequence for other rules, which means that "fulfilment" is a state that exists in the edge "rule-[fulfilled]->duty".

For example, you can have 2 permissions for 2 assets that point to the same duty of €5. You need to fulfil the duty individually, once for each permission rule (it is not BOGOF).

The outcome of evaluating the duty ("fulfilment state") belongs to the relationship.

[simonstey]

The outcome of evaluating the duty ("fulfilment state") belongs to the relationship.

and I'm not saying that it shouldn't.. only that the reason ODRL isn't providing means for "encoding" this as triples is that it was meant to be always evaluated on the fly.

[joshcornejo]

I know most of ODRL is historically for the context of media, but we're moving to the world of micro-transactions / embeddings / multi-attributions / recurring-engagement. Apparently, "very fast".

For on-the-fly evaluation, I've done it.

I've implemented two behaviours:

• "Fire-and-forget" (there is no need to know if the duty was fulfilled)
• "Wait" (the answer to a request isn't returned until notification of fulfilment of a duty).

I think the A) and B) should be normative (I think this is entering the realm of "protocol" above just "semantics").

[simonstey]

also there is:

2.6.5 Duty property with a Permission

A Duty MAY be specified as a pre-condition that requires fulfillment using the duty property relationship from the Permission to the Duty.

If a Permission has several Duties then all of the Duties MUST be agreed to be fulfilled. If several Permissions refer to the same Duty (via its uid property), then the Duty only has to be fulfilled once.

[joshcornejo]

If several Permissions refer to the same Duty (via its uid property), then the Duty only has to be fulfilled once.

That would make an unmanageable explosion of Duties if they are all "€5 per asset".

Even further, to simplify the work of a product manager, and as prices have a separate lifecycle from Policies and Assets, my duties have the preference to be specified as:

go and find the price for the <asset, action> inside a pricing list in this URI

Otherwise, you have to release a policy every time you change a price and if prices are dynamic on an agreement, you have to reissue all agreements.