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 Thursday, 7 September 2017 10:59:10 UTC