Split LeftOperands into constraints and refinements

[riannella]

Split the list of LeftOperands into those applicable for constraints and those for refinements.

Note: the LeftOperands are all non-normative.

[nitmws]

A note on the refinement of actions after suggesting changes to the definitions of LeftOperands in #284

I'm afraid that it will be hard to draw a clear line between Constraints with a LeftOperand referring to the action of a Rule which are used as constraint of a Rule or as a refinement of an action without any further help (or relationships).

The definitions:

• The refinement property is defined for the Action Class in the current IM as: "one or more refinement property values (of type Constraint) that refine the semantics of the Action operation."
• the IM section 2.5.4 talks about "refinement property with an Action": "An Action MAY include the refinement property to indicate a Constraint/Logical Constraint that narrows the semantics of the Action operation directly. To meet this condition of narrower semantics for the Action, all of the Constraints/Logical Constraints referenced by the refinement property MUST be satisfied."

From the discussions resulting in the new refinement property I recall statements like "the action may be generic, the refinement should add how exactly it should be exercised".
But this is exactly what 20 out of 32 LeftOperands (see #284) do: e.g. Datetime refines any action to the point in time when it may be exercised, it narrows the semantics of "print" to "print only on 22 November 2017 or later". What is the difference to our main example of narrowing the "compensate" action to "compensate by paying 30 EUR" - which uses the odrl:compensate with the refinement odrl:paymentAmount?

With my experience in defining (IPTC) taxonomies I see this difference - and maybe a solution:
The odrl:compensate is defined as "To compensate by transfer of some amount of value, if defined, for using or selling the Asset." This definition shouts out "I need the definition of the amount of value, else I cannot be exercised". In other words: using odrl:compensate without a refinement doesn't make sense. And this need can be fulfilled by the odrl:paymentAmount LeftOperand.
Actions like display, distribute, index, modify, print or stream can be exercised without any further refinement.
Actions like attribute need more: it may be required with which term/name/label the attribution should be exercised,

My conclusion: I suggest to set a relationship like odrl:needsRefinement (with a boolean value "true", default: "false") for these actions who really need that. And a refinement SHOULD be applied only to Actions with odrl:needsRefinement "true".
A next step would be having a relationship like odrl:toBeRefinedAction pointing from a LeftOperand to an Action it may be used with.

[riannella]

My (editorial-only) suggestion is that we update the narrative in the table in Section 3.3 ODRL Profile Mechanism.
Where it says:

Additional Constraint left operands:
Create an instance of the LeftOperand class

we update to:

Additional Constraint left operands:
Create an instance of the LeftOperand class and optionally indicate if the Profile recommends this to be used with the constraint or refinement property

This way, we let Profile designers decide.

[nitmws]

@riannella re your comment:

1. We need to define a relationship expressing "this LeftOperand can be used for the semantic refinement of that Action instance" - e.g. odrl:toBeRefinedAction
2. I agree, to let a profile maker apply such a relationship the 3.3. ODRL Profile Mechanism must be changed.
3. We could outsource this decision, but I'm not convinced that this will be done properly.
   3.1. this may cause problems with interoperability: profile A defines odrl:count should be used with a Rule constraint, profile B defines odrl:count should be used with an Action refinement. And a Policy must refer to both profile A and profile B by design reasons. What should the implementer do?
   3.2 A logical issue is, it was as I recall raised by @simonstey, that a refinement cannot be satisfied by its own. Our frequently used example constrains the odrl:compensate by an odrl:payAmount of some bucks. Can the Constraint "payAmount 50 EUR" be not-satisfied? Simon said relevant for the logic of the Rule is that the action is exercised with the refinement and not without the refinement. Only if the action is exercised with satisfying the refinement it is logically "exercised".
   By that I'm not sure if all the LeftOperands can be defined for a use with Rule constraint or with Action refinement by the thoughts of a profile maker.

[riannella]

1. If we add a new feature (non-editorial) then we need to do the CR process again 😬

2. ok

3.1 I would assume, if this was the case, then the implementor would support both options for count.

3.2 So we should then leave it alone, and not say anything? (I ok with that too)

[nitmws]

re @riannella

re 1. What is an alternative to indicate "this LeftOperand instance should be used with refinement Constraints" or "this LeftOperand instance should be used with refinement Constraints" (as default relationship) without defining a new feature triggering a new CR?
Could this be a free-text table acting as non-normative guideline with a LeftOperand in each row and columns for constraint Constraints and refinement Constraint and an "x" shows the preferred use? Should this be written down in a special Note document?

re 3. The current formal definition in 2.5.4 of the IM is:
An Action MAY include the refinement property to indicate a Constraint/Logical Constraint that narrows the semantics of the Action operation directly. To meet this condition of narrower semantics for the Action, all of the Constraints/Logical Constraints referenced by the refinement property MUST be satisfied.
How to satisfy a constraint this is defined in 2.5.1 of the IM:
A Constraint class is used for expressions which compare two operands (which are not Constraints) by one relational operator. If the comparison returns a match the Constraint is satisfied, otherwise it is not satisfied. The Constraint class formulates a comparison expression, such as, the number of usages (the leftOperand) must be smaller than (the operator) the number 10 (the rightOperand).

Apply these definitions to our frequently used refinement of an action:
<odrl:payAmount> <odrl:eq> "50 EUR" .
odrl:payAmount is defined as "The amount of a financial payment. " therefore "is the amount of a financial payment equal to 50 EUR" needs to be compared, but how? Does the party having to exercise the payment check it accounts for available 50 EUR, or does it have to check if its accounting department is able to pay 50 EUR, or does a manager has to show thumbs up for paying 50 EUR to set the Constraint to Satisfied or Not-Satisfied?

My summary of that: the IM does not define something wrong but it leaves the evaluation of a refinement of an action open to random ways of comparing - this does not support interoperability.
Is clarifying this in a Best Practice Note an option? I still think that @simonstey 's outline would be a good description.

[riannella]

It is best (if we can) to resolve this with editorial updates to the narrative.

I was under the impression that we (ie the WG) should not be determining if a Constraint instance should be used with the constraint or refinement property?
(based on the odrl:count example above).

The specs says that when a Constraint instance is used with a constraint, it is a condition that applies to the Rule, and when used as a refinement, it narrows the semantics of the Action.

What else can we say?

As for the evaluation of the refinement - we are still talking about the "black box" approach. If you are refining odrl:compensate with odrl:payAmount=AUD100 the implementation will just return satisfied or not. (But I don't want to get back into talking about the ODRL Evaluator again !!!!)

[nitmws]

I've raised two concerns about the use of LeftOperand in my comments:

1. My concerns of constraint Constraint vs refinement Constraint are in fact only about the LeftOperand instances.
   The IM specs regarding the use of LeftOperand instances are ok, I see no need to change them.
   I suggested to advise users which of the LeftOperand instances listed in the Common Vocabulary should be used with constraint or refinement - or both. And I pointed at the fact that about 20 of theses LeftOperand instances are related to the Action of a rule which will raise the question by users: create a Rule constraint or an Action refinement with that LeftOperand?
   Note: if there is no problem to apply a Constraint with such an action-related LeftOperand as constraint or as refinement, why do we have these two variants at all?
2. I point at an issue raised by @simonstey that if a refinement Constraint is satisfied is very hard to evaluate. The only realistic evaluation is if an action is exercised WITH all its refinements in a "satisfied" state. If this view is shared by the WG the narrative about that should be edited. E.g. in IM 2.5.4 ... "To meet this condition of narrower semantics for the Action, all of the Constraints/Logical Constraints referenced by the refinement property MUST be used as generating a satisfied state."
   Note: by my experience with the implementation of IPTC standards I don't support a heavy use of "black boxes" as this has a negative impact on interoperability. And this should not be the case for a standard used in the area of rights.

[riannella]

1. I suggest we add the following narrative text to the beginning of Section 4.5 of the Vocab spec that outlines the use of LeftOperands:

This section contains instances of LeftOperands that can be used as the leftOperand of a Constraint . The LeftOperands may be used in Constraints for either the constraint property (applying to a Rule) or a refinement property (applying to the Action). ODRL policy expressions should utilise Constraints that are appropriate for the intended semantics of the LeftOperand.

2. I am Ok with that narrative update.

[riannella]

updated