[poe] On 2.6.8 Rule Active State Processing

simonstey has just created a new issue for https://github.com/w3c/poe:

== On 2.6.8 Rule Active State Processing ==
> ODRL **processors** ...

what's an ODRL _processor_? we only define ODRL _validator_ and ODRL _evaluator_ in the [Terminology](https://w3c.github.io/poe/model/#terminology). 

> ... are required to determine **if a Rule has met ~~their~~ _its_ intended action performance.** That is; is the action of a Permission rule allowed, is the action of a Prohibition rule being complied, and has the action of a Duty rule been fulfilled.

I have no clue what _"intended action performance"_ is/means..
Why do we need this first paragraph at all? As long as processor==evaluator it's obsolete.

----
> An ODRL Validator MUST **first** ensure that the ~~Policy rules~~ _encoded policy expressions_ meet the conformance requirements of the ODRL Information Model. For example, this includes property cardinality and relationship checking.

and after that? what's 2nd?
 
----
> An ODRL Evaluator MUST **then** evaluate if the constraint properties of a Rule are satisfied to determine if the Rule is Active. If a Rule has no constraint properties, then it is always Active. A Non-Active Rule means that no further processing is required at this time and no outcomes can be determined from the Rule.

ooh.. I see.. I guess what you wanted to say is that an ODRL evaluator obviously needs syntactically valid/well-formed ODRL expressions to work with. 
Maybe we could adapt a similar wording as used for SHACL?

https://www.w3.org/TR/shacl/#ill-formed-shape-graphs
> If the shapes graph contains ill-formed nodes, then the result of the validation process is undefined. A SHACL processor SHOULD produce a failure in this case. 

https://www.w3.org/TR/shacl/#shapesGraphWellFormed
> SHACL validation engines are not strictly required to check whether the shapes graph is well-formed. Implementations that do perform such checks (e.g., when the shapes graph is installed in the system, or before or during the validation) SHOULD use the property sh:shapesGraphWellFormed to inform the consumer of the validation report about this fact. If a SHACL instance of sh:ValidationReport in the results graph has true as the value for sh:shapesGraphWellFormed then the processor was certain that the shapes graph that was used for the validation process has passed all SHACL syntax rules (as summarized in B. Summary of SHACL Syntax Rules) during the validation process. 

----
> Once a Rule has been determined to be Active, then the ODRL Evaluator MUST:
> 
>    + Allow the action of a Permission rule. This includes evaluating, and confirming, the fulfilled state of the duty properties of the Permission.
>    + Disallow the action of a Prohibition rule. This includes determining if the Prohibition has been violated (by the action being exercised) and if remedy Duties have been fulfilled.
>    + Confirm fulfilment of the action of a Duty rule. This includes determining if the Duty has not been fulfilled and the required consequence Duties have also been fulfilled.

This part should be replaced/updated, reflecting @nitmws recently [suggested interpretation](https://lists.w3.org/Archives/Member/member-poe-wg/2017Aug/0025.html):
> Beyond the “active” state, but based on it:
> 
>    + To set the state “fulfilled” of a Duty the Duty must be active and its action must be executed. If one of the two requirements to not apply the Duty is not-fulfilled.
>    + If a Permission has one or more Duties related by duty all of them must be fulfilled to keep the Permission “active”. If at least one duty Duty is not fulfilled, the Permission is “not-active”.
>    + A Prohibition has the state “not-violated” if its action has not been exercised. It has the state “violated” if the action has been exercised, in this case the state “not-violated” can be regained if all (optional) Remedies have been fulfilled.

Please view or discuss this issue at https://github.com/w3c/poe/issues/226 using your GitHub account

Received on Tuesday, 29 August 2017 06:52:05 UTC