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

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

-----Original Message-----
From: Renato Iannella [mailto:renato.iannella@monegraph.com] 
Sent: Wednesday, September 6, 2017 6:39 AM
To: Michael Steidl (IPTC) <mdirector@iptc.org>; Benedict Whittam Smith
<benedict.whittamsmith@thomsonreuters.com>
Cc: POE Public <public-poe-wg@w3.org>
Subject: Re: What exactly is stated by Non-/Active?

So what do we do?

Perhaps we just assert the MUST requirements for an ODRL Evaluator:

=====
An ODRL Evaluator MUST be able to process Rules to:
- Determine if a Constraint has been satisfied (for Rules and Actions)
- Determine if a Duty has been fulfilled
- Determine if a Permission is allowed to be exercised
- Determine if a Prohibition has not been exercised
- ?
=====

Implementations can interpret *how* to do this that best fits their needs,
but the *outcome* will be the same.


R

Received on Wednesday, 6 September 2017 08:31:07 UTC