Of triggered actions within obligations

[joshcornejo]

Not sure if this lands in semantics, best practices or somewhere/nowhere else.

There are 3 possible behaviours for triggered actions within duties:

• one-off: These can/should be actionable only once, an example is odrl:delete.
• recurring: These can/should be actioned every time the duty is triggered, an example is odrl:attribute.
• ambiguous: These can be actioned either way, for example, odrl: compensate could be both a single trigger (e.g. when you purchase an asset) or recurring (e.g. every time the asset is used)

The use of odrl:unitOfCount has been considered, although its use appears to count in a different plane ("indicate the unit entity"), and it is 'left to the implementer' to interpret (which units/etc?), it is therefore ambiguous (not all instances of use will indicate a relationship to the trigger of the Duty).

These could lead to different interpretations of how to 'rate-limit' upstream (back to the trigger point) and downstream (any post-processor).

There are 2 possible ways to express the expected behaviour:

• Duty constraint: use of a LeftOperand :recurrence with a defined range (e.g. :one-off / :recurring),
• Trigger property: add a property (since it's an edge "a label"?) to the odrl:failure that surfaces the behaviour.

There are advantages and disadvantages to both:

Constraint:

• keeps in line with the current structure of the standard,
• narrows the reusability of the rule,
• adds a new state to duties, which has to be checked pre-evaluation to assess the need of evaluation.

A label:

• can bypass 'processing' rules that no longer need trigger,
• introduces new structures to ODRL.

I prefer the leftOperand/constraint approach, but open to discussion.

[vroddon]

Leavin aside payments, for which some more constructs exist, you pose an interesting question.
By default, I would interpret that the duty has to be executed every time.
Can you perhaps describe further this case?

one-off: These can/should be actionable only once, an example is odrl:delete.

[joshcornejo]

These are all "long use case" related to find the right context. For example, it will be difficult to find some "valid" use case for odrl:play after they are supposed to odrl:delete an asset.

Perhaps, alternative cases could be:

• assigner can choose if they want to be odrl:inform once or every time odrl:play,
• assigner could be odrl:attribute, but only the first time, but no further times.

And I thought about it - odrl:count within the Duty could be used, but i am not sure it is the right approach.

[vroddon]

As an alternative solution, having an ontology of actions, as many times vindicated by @fornaran, would allow for these to have a property specifying this feature.
In the meantime... do we all agree that the current meaning is "every time"?