How to evaluate the results of Permission, Prohibition and Duty

[nitmws]

I've created a draft of guidelines for evaluating the result of a Permission, Prohibition or Duty
https://docs.google.com/spreadsheets/d/1vej4EwEZjUM2yYJwBggJxHlSTCinyuMPCulKIeHNTA0/edit?usp=sharing
... in the lower section of the table.

The result of a Permission is named Has-Permission or No-Permission, of Prohibition Is-Accepted or Not-Accepted and Duty the well known Fulfilled or Not-Fulfilled.
The naming of Permission and Prohibition results are my suggestion.

[nitmws]

Re the definitions of the obligation property (2.5.4), duty property (2.5.5) and remedy property (2.5.7)
As outlined in #221 (comment) the evaluation of the Duty rules is inconsistent.
I suggest to follow simple evaluation rules:

• the Active/Not-Active status of duty, remedy and consequence has not impact on the evaluation of this status of the Permission, Prohibition and Duty including it - greyed out in the guidelines table.
• for the evaluation of results of Permission, Prohibition and Duty the Active/Not-Active state of this class instance is relevant and the evaluated results of property values.

(This split of evaluating Active/Not-Active and the Rule results was/is a free decision, the evaluation of ODRL Rules would also be possible without this split.)

[riannella]

I really find Active/Non-Active confusing with the 3 Rule types (its the same as using Effective).

Active has an even wider definition: http://www.thefreedictionary.com/active

So, when it says a "Duty is Not-Active", hence not functioning, not currently in use or effect, you get the sense that you don't have to do anything...

[simonstey]

So, when it says a "Duty is Not-Active", hence not functioning, not currently in use or effect, you get the sense that you don't have to do anything...

which reflects the intended semantics.

Example:

<http://example.com/policy:42>
  a odrl:Policy ;
  odrl:permission [
    a odrl:Permission ;
    odrl:target ex:asset_9898 ;
    odrl:action odrl:reproduce ;
    odrl:assigner ex:Alice ;
    odrl:assignee ex:Bob ;
    odrl:duty [ 
      a odrl:Duty ;
      odrl:action odrl:obtainConsent ;
      odrl:consentingParty ex:Alice ;
      odrl:constraint [ 
        odrl:leftOperand time:dayOfWeek;
        odrl:operator odrl:isAnyOf ;
        odrl:rightOperand time:Saturday, time:Sunday ;
      ]
    ]
  ] .

ex:Bob can exercise his permission to odrl:reproduce asset ex:asset_9898 on any day other than time:Saturday or time:Sunday without any obligations.

On weekends, however, he has to odrl:obtainConsent from ex:Alice first before he's granted permission to odrl:reproduce asset ex:asset_9898.

[riannella]

Hmmm....

So, tomorrow (saturday) Bob gets consent from Alice, so reproduces the Asset.

Next saturday, why does Bob have to "fulfill" this Duty again? (He already got consent from Alice on a Saturday)

[nitmws]

Re @riannella 's question in the previous comment: maybe the duty action obtainConsent does not fit perfectly in this example. A duty like "pay 10 EUR" would fit better: for getting a permission from Monday thru Friday no Duty is Active, only on Saturdays and Sundays the duty is Active = you have to pay.

[simonstey]

So, tomorrow (saturday) Bob gets consent from Alice, so reproduces the Asset.

Next saturday, why does Bob have to "fulfill" this Duty again? (He already got consent from Alice on a Saturday)

the spec only says:

The Duty specifies agreed Actions that MUST be fulfilled.

but does not specify how you have to check whether a duty is fulfilled or not. Previously it said that you can use constraints for that, but generally you don't have to.

As such it's up to implementors to decide whether duties have to be fulfilled every time they are evaluated or whether duties can keep their state of "fulfilledness".

TL&DR: ODRL does not specify whether switching duties on/off has any effect on their "fulfilledness".

[nitmws]

My conclusion as of 28 August: the initial posting of this issue was based on an understanding of "active" not aligning what the IM has in mind after merging many occurrences of "in effect" - see #225.
The result: ODRL needs a clear definition of "active"/"in effect", a proper description in the different contexts of Permission, Prohibition and Duty and a consistent use of the finally agreed term.

An open issue is the question: by which exact activity should the action of a Duty get the state "exercised"? Either ODRL defines one or ODRL defines that this could or even should be defined by the duty actions specified by a Profile. (E.g.: I fully support that "payAmount" could be exercised by adding the amount to list of amounts which are paid monthly = in 10 days and not now.)