Re: [poe] isNeccessaryFor

My  views on the current isNecessaryFor (IM of 31 January) in 3.8.1:
- I put this issue on the top - frankly it came up while writing all 
the bullets below: **is our thinking about this isNecessaryFor going 
in the right direction?** A logic combination of two constraints can 
be expressed by the operators or, xor or and. And if the left and the 
right operand must be satisfied then "and" should be use - and nothing
 else. But I think this isNecessaryFor is made to communicate: **this 
constraint must be processed at  the time the Action of a Rule should 
be executed because the result of a constraint (satisfied or not) 
referring to this Action may change over time** - and not: this 
constraint must deliver a result before another constraint is 
processed.. 
Practical view: checking if a time limit or a count limit is met 
should be checked when the action of the Rule should be executed and 
not let's say 2 or 5 or 15 minutes earlier.
(Was how to deal with the temporal change of left operand values ever 
discussed for ODRL? I can't recall it.)
Conclusion: we need this property for Constraint: 
**hasProcessAtActionTimeNeed** (ok, not short) - data type boolean, 
default value false. Definition: "If the value is true this constraint
 must be processed as close as possible to the time of executing the 
action it refers to as its result may change over time. This applies 
only to Left Operands of a constraint refering to an action."

My comments below are based on the previous discussions of this issue:

- re isNecessaryFor operator spec: 
-- My basic concern: isNecessaryFor doesn't fit into the context of 
Constraint Relations. They are made "for two constraints to be 
compared and processed accordingly" and the basic requirement for a 
Constraint as such is to deliver a boolean result: is the constraint 
satisfied or not. isNecessaryFor only defines that the leftOperand is 
a prerequisite of the right operand - but what's next??? Nothing like 
or, xor or and is defined -  even not as default value. Is it an 
implicit requirement to have 2 Constraint Relations with exactly the 
same left and right operands, one with isNecessaryFor and the other 
one with an or, xor or and operator?
-- What does "prerequisite"really mean - and what is the difference to
 the and operator? I interpret it as "the left operand must have 
delivered a result before the right operand is processed", this 
defines a temporal sequence for processing constraint results. If this
 is the intention then I suggest to rename the operator to 
"hasResultBefore". This also opens the logic relationships between the
 constraints (see my note above) to or, xor and "and". And we should 
comment/explain/define that the use of hasResultBefore only makes 
sense if the result of the left operand Constraint is expected to 
change over time, e.g. count, "live" times, etc. To require that the 
size of a digital image must deliver a result before the distribution 
channel constraint is checked doesn't make sense in practice.
-- conclusion: we must change the specification

- re "The isNecessaryFor operator ..." paragraph:
-- re "... unsatisfiable Constraint  ...": the spec of Constraint 
(first para in 3.8) defines if comparing left and right operand 
results is **true** then the Constraint is satisfied. Therefore: if 
its result is false it is unsatified. But what is meant by this use of
 "unsatisfied Constraint"? I interpret it means that for some reason 
the left and the right operand cannot be compared (e.g. because the 
result for the left operand cannot be retrieved). 
-- re " "recursive chaining" ": first there is a typo: "to many times"
 should read "too many times" I guess. And this raises the question: 
how many times is below "too many"? I understood that   @simonstey 's 
main concern is a circular chaining: c1 -> c2 -> c3 -> c1 - and I 
share this concern as the ODRL spec cannot stop that at the level of 
formal definitions. Only in the free-text part of the spec it could be
 said this should not be the case.
- re processing model, item 8:
-- re "... the left operand Constraint MUST be satisfied ..." again: 
do we want to hardwire that the result of the left operand MUST be 
true? Or does this operator define a temporal sequence for processing.
 Something like "... the left operand Constraint MUST be processed 
first, after its result is available the right operand Constraint MUST
 be processed." would fit better this purpose.
- re processing model, item 9 and 10 
-- again: this use of "unsatisfiable" mixes the result "false" of a 
constraint with "processing this constraint does not deliver a result"
 - and the latter is meant. 
-- I think the rule must be more strict and I suggest to append at the
 end of both item "... a warning message and the processing of the 
policy including this Constraint must be aborted."

-- 
GitHub Notification of comment by nitmws
Please view or discuss this issue at 
https://github.com/w3c/poe/issues/98#issuecomment-276307772 using your
 GitHub account

Received on Tuesday, 31 January 2017 08:52:48 UTC