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 12:09:11 UTC