RE: What exactly is stated by Non-/Active? @IM 9 Sept

I've matched Ben's concerns below with the IM version of 9 September:

In general: we should focus on the semantics of terms and not on their
"labels" (= words), I feel some different words below mean in fact the same.

Re "processing model" vs "evaluation model": I see no big semantic
differences between them as evaluation is a specific kind of processing. I
could live with defining in 2.6.8 a Rule Evaluation (Rule Evaluator) and to
replace the word "processing" with "evaluation" in this section. (I hope
this fits in all cases :-) )

Re "business implementations" and "software implementations": I never
requested that should be distinguished in the IM - only we should be aware
of that in our discussion.

Re the states "satisfied/not-satisified ... not-needed-to-be exercised" vs
"active/not-active .. not-fulfilled"
* 2.6.8 in this IM version has reduced these "many states" to a simple,
small set
* My question what exactly is meant/stated by Non-/Active has not been
answered by anybody yet ...
* ... therefore I can't match Non-/Active against the current terms in
2.6.8.

Re "Then there are processing rules ..."
* the discussions of issues on Github agreed to merge all what's relevant
for evaluating a Rule in a single section -> now 2.6.8
* The "first rule ... " points at an issue of cases of terms - and their
different meanings:
if an evaluation rule uses "constraint" it means this property of a Rule and
not all existing instances of Constraints. If the constraint (or refinement)
property refers to a Logical Constraint class this class will refer to some
instances of the Constraint class, but these instances are not a
"constraint" of Rule or a "refinement" of an Action as they are not referred
to by a property of this name.

Re "Part of my basic point ...": 
* I fully agree to "to ensure logical consistency, i.e the evaluator" as
stated already a couple of times -  but I guess there are slightly different
views what is required to ensure that.
* Which one of "these decisions" are implementation specific ...
* ... and what does "implementation specific" mean = what flexibility of
interpretation is meant by that?

Best,
Michael

-----Original Message-----
From: benedict.whittamsmith@thomsonreuters.com
[mailto:benedict.whittamsmith@thomsonreuters.com] 
Sent: Friday, September 8, 2017 2:08 PM
To: renato.iannella@monegraph.com; public-poe-wg@w3.org
Subject: RE: What exactly is stated by Non-/Active?

No - it does not. It's considerably more complex than my view point. I'm
very happy for rules to simply be active (in which case they can be
exercised) or not-active (in which case they can't).

Below we're being asked to define a processing model. We never agreed to do
that. It's implementation specific. We agreed to provide a validation model
and an evaluation model.

We're asked to make the distinction between "business implementations" and
"software implementations". That's new to me.

We're also asked to distinguish between the following states:
satisfied/not-satisfied; exercised/not-exercised; fulfilled/not-fulfilled;
allowed-to-be-exercised/not-allowed-to-be-exercised; violated/not-violated;
should-be-exercised/not-needed-to-be-exercised.

Not in my implementation! All I need is active/not-active;
satisfied/not-satisfied; fulfilled/not-fulfilled.

(Part of my basic point is that many of these decisions are implementation
specific. We, in the standard, just need to give the minimal set to ensure
logical consistency, i.e the evaluator. My implementation would use this
set. Others' tastes may be more baroque. Not my business - nor that of the
standard.)

Then there are the processing rules. I think what we need is already
explicit in the IM. Then first rule given is wrong - not all refinements of
an action/party/asset should be satisfied if we're using logical
constraints. It says so in the IM (see Example 14).

SIMON: You ask why I mark D1 as un-fulfilled although R1 is satisfied in row
2 in Example 22. Imagine a highly-distributed implementation. One component
(that knows how to count) might mark the constraint as satisfied. Another
(that knows how to pay) might then go on to fulfil the duty. But it's been
waiting for the first to report the satisfaction of the constraint before
paying.

Ben
________________________________________
From: Renato Iannella [renato.iannella@monegraph.com]
Sent: 07 September 2017 11:58
To: POE Public
Subject: Re: What exactly is stated by Non-/Active?

Thanks Michael.that is looking good.

To the rest of the WG, are there any serious objections to this approach
described below?
(or any feedback/updates?)

@ben and @simon  - does it fit your viewpoints?

If ok, then the editors will make it section 2.6.8 of the ODRL IM (with some
word-smithing ;-)

The goal is to have a version by Monday for voting for CR.

Renato


> On 6 Sep 2017, at 18:30, Michael Steidl (IPTC) <mdirector@iptc.org> wrote:
>
> Two notes on that:
>
> 1) re "implementations": we should make a distinction between 
> "business implementations" and "software implementations"
> - business ... =  a party uses ODRL for retrieving rights-relevant 
> information. In this case the party needs clear rules for what to 
> infer from e.g. Not-Satisfied constraints regarding  the final outcome 
> of a Rule - this should not be open to individual interpretations. 
> (And such rules should drive requirements for software 
> implementations.)
> - software ... = how the evaluation outlined by the ODRL IM is 
> translated into software is completely up to the implementor. It is 
> only relevant to deliver results as defined by the IM.
>
> 2) re the ODRL Evaluator rules below: that goes in the right direction 
> for me, thanks Renato.
> My a bit more granular version is:
> - Determine if constraints of a Rule and if refinements of an Action 
> of this Rule have been Satisfied
> - Determine if a Duty (used by duty in Permissions, remedy in 
> Prohibitions, consequence in some kinds of a Duty) has been fulfilled
> - Determine if a Permission is allowed to be exercised
> - Determine if a Prohibition is violated (violated = the requirement 
> not to exercise an action has not been fulfilled)
> - Determine if an Obligation should be exercised.
>
> The statement "An ODRL Evaluator MUST be able to process Rules to ... 
> (all
> items) ..." is a first level specification.
>
> I think the IM MUST also define how these 5 listed to-be-determined 
> states have to be evaluated by generic rules as second level
specification:
>
> * Constraints (used with constraint or refinement): the IM Processing 
> Rules should state for the (atomic) Constraints that the evaluation of 
> their Satisfied state heavily relies on the semantics of the left 
> operands and they are covered by Profiles. (Note: the Core IM does not 
> define any leftOperand - conclusion: for any Constraint a Profile is 
> required!) The rules for Logical Constraints are in 2.5.2.
>
> * Special and generic rule for Duty, Permission, Prohibition and
Obligation:
> if any of the existing constraints/refinements of its action is 
> Not-Satisfied is has to be considered as not-existing for any further 
> evaluations.
>
> * Duty (used with duty, remedy, consequence): to be Fulfilled all its 
> existing constraints/refinements of its action must be Satisfied; the 
> action must be exercised, if not all existing consequences must be 
> Fulfilled. Else the Duty is Not-Fulfilled.
>
> * Permission: to be Allowed-to-be-exercised all its existing 
> constraints/refinements of its action must be Satisfied, all its 
> duty(ies) must be Fulfilled. Else the Permission should not be exercised.
>
> * Prohibition: to be Not-Violated its constraints/refinements of its 
> action must be Satisfied; its action must not be exercised, if it has 
> been exercised all existing remedy(ies) must be Fulfilled. Else the 
> Permission has been Violated.
>
> * Obligation (used with obligation: to be in a Should-be-exercised 
> state its constraints/refinements of its action must be Satisfied; the 
> action must be exercised, if not all existing consequences must be 
> Fulfilled. Else the Obligation does not need to be exercised.
>
> * MS note: what I'm missing in this context is the quite relevant role 
> of target and assignee. I suggest to add this "Note: The evaluation 
> and the states of Permission, Prohibition and Obligation apply only to 
> assignees and targets of this Rule." to the Rules Processing section.
>
> ------------
>
> I consider such Rule-type specific evaluation rules as sufficient. (In 
> an Implementation Note we may give some more software-minded 
> guidelines for implementing that.)
>
> Does anybody object to this quite limited set of processing rules?
>
> And does anybody object if we retire the magic term "Non-/Active"? 
> (For me it is too generic and generic semantics do not fit in all 
> different types of rules. For this reason too unclear to be of help in 
> an evaluation rule - and Truth Tables can be populated with the 
> different names of states - or maybe acronyms for them.)
>
> Best,
> Michael

Received on Friday, 8 September 2017 15:28:04 UTC