RE: What exactly is stated by Non-/Active?

I would like to underline the basic need for a rights expression language by
an IPTC/RightsML view - and copy and paste from
https://iptc.org/standards/rightsml: 
Rights Expression Languages are machine-readable languages used to convey
the rights and restrictions associated with a particular asset. They codify
the permissible actions (under certain duties and constraints) for an asset
when it's made available by one party to another.
(Then we claim RightsML, based on ODRL, covers that goal.)

Conclusion regarding ODRL: The goal of a Permission is to convey if the
assignee may take a specific action on a specific asset, or not.
If for a Permission instance the not-/satisfied state of the constraints and
refinements is evaluated and if the not-/fulfilled state of duties is
evaluated ODRL needs also a processing rule to evaluate from these
"sub-evaluations" the Permission's state not-/permitted to take the action.
And this should be included in the Rule Processing, not only the evaluation
of the properties of a Rule. (And a similar need applies to Prohibition and
Duty)

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 14:13:09 UTC