w3c
Synchronous and asynchronous duty
In the case of odrl:remedy and odrl:consequence it is unlikely this requirement is necessary, but for an odrl:duty it is possible to have one of the following two scenarios:
Fire & forget or Asynchronous: an odrl:Permission triggers a duty, but waiting is unnecessary or creates an "impossible loop" (e.g. can't have odrl:Attribution until the asset is executing the action odrl:play).
Synchronous: the odrl:Duty must be fulfilled before the evaluation calculation is returned to the caller.
As such, the relationship between odrl:Rule and an odrl:Duty requires an attribute ex:wait to let the evaluator knows what type of behaviour is expected.
Notes:
- The evaluation for the triple
[ actor, action, asset ]will return a callback uuid, an expiry time, and the status of the duties - A different call
[ actor, action, asset ]will return the same uuid, until an expiration time, then a new cycle will start - A separate API polling uuid is recommended
Same diagram as issue #95 to understand why it is an attribute of the relationship.
