On 2.6.8 Rule Active State Processing

simonstey commented 7 years ago

ODRL processors ...

what's an ODRL processor? we only define ODRL validator and ODRL evaluator in the 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:

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.

nitmws commented 7 years ago

I've written down similar issues in https://lists.w3.org/Archives/Public/public-poe-wg/2017Aug/0012.html

riannella commented 7 years ago

Updated the Rule Active State Processing based on this feedback. Also changed "odrl processing" to "odrl validation" in other sections

nitmws commented 7 years ago

re @riannella 's update: The different evaluation workflows for Rules make it hard to write down the evaluation of a Permission in a bullet proof way in 2.6.8 :

Step 1: a generic evaluation if a Rule - Permission included - is Active
Step 2: "Once a Rule has been determined to be Active, the Evaluator MUST " + "Evaluate the fulfilled state of all duty properties of the Permission. If confirmed, then the Permission rule is Active and the action of the rule is allowed, otherwise the rule is Not-Active."

I hope all readers will get that the Active state generated by step 1 is only an interim state for a Permission, the "real" Active state is evaluated in step 2.

Pros and cons on that are welcome.

nitmws commented 7 years ago

I've updated the draft of an ODRL Evaluation Workflow to version 4, see https://docs.google.com/spreadsheets/d/1vej4EwEZjUM2yYJwBggJxHlSTCinyuMPCulKIeHNTA0/edit?usp=sharing

riannella commented 7 years ago

Perhaps, the rule-level "Active"/"Not-Active" should be changed to "Applicable"/"Not-Applicable" to reduce any potential confusion with the states of the individual rules?

simonstey commented 7 years ago

Perhaps, the rule-level "Active"/"Not-Active" should be changed to "Applicable"/"Not-Applicable" to reduce any potential confusion with the states of the individual rules?

well, depending on the use case we may actually need both:

UC1: Identify all (currently) active rules of a policy

https://www.w3.org/2016/poe/wiki/Evaluator:

The task of an ODRL Evaluator is to determine which ~~Permission(s) or Prohibitions~~ Rules are in effect.

Example:

:policy101 a odrl:Set ;
    ### active ###
    odrl:permission [ 
        odrl:action odrl:print ;
    ] .

:policy102 a odrl:Set ;
    ### not active ###
    odrl:permission [ 
        odrl:action odrl:print ;
        odrl:constraint [ 
            odrl:leftOperand odrl:dateTime;
            odrl:operator odrl:lt ;
            odrl:rightOperand "2000-12-31" ;
        ]
    ] .

:policy103 a odrl:Set ;
    ### active ###
    odrl:permission [
        odrl:action odrl:print ;
    ] ;

    ### active ###
    odrl:prohibition [ 
        odrl:action odrl:display ;
    ] .

:policy104 a odrl:Set ;
    ### not active ###
    odrl:obligation [ 
        odrl:action odrl:inform ;
        odrl:constraint [ 
            odrl:leftOperand odrl:dateTime;
            odrl:operator odrl:lt ;
            odrl:rightOperand "2000-12-31" ;
        ]
    ] ;

    ### active ###
    odrl:obligation [ 
        odrl:action odrl:compensate;
        odrl:constraint [ 
            odrl:leftOperand odrl:dateTime;
            odrl:operator odrl:gt ;
            odrl:rightOperand "2000-12-30" ;
        ]
    ] .

UC2: Determine whether an ODRL Rule is applicable for a given asset and/or assignee

From ODRL Evaluator Rules by @philA:

An ODRL Evaluator determines whether an ODRL Rule is in effect for a given asset. It MAY assume that the given ODRL Policy has been validated by an ODRL Validator. [...] The latter example implies that an OE must also be able to accept a third parameter: the assignee. So you can ask it questions like, "is Policy X in effect for Asset Y for Assignee Z?"

as well as

@nitmws in How Rules become Active #221:

This raises the question: a Rule may have also an assigner and an assignee and should have a target - should they be matched too against the value of a planned action?

In other words: is a Rule with assignee = "http://examples.com/company/4711" active if it is evaluated by assignee = "http://examples.com/company/9912"?

I guess ODRL users will expect it is not-active, as this is the same situation as with not satisfied Constraint(s).

Example:

:policy201 a odrl:Set ;
    ### active ###
    odrl:permission [ 
        odrl:target :Asset1 ;
        odrl:assignee :Alice ;
        odrl:action odrl:print ;
    ] .

Q: Is :Alice permitted to print :Asset1? A: Yes (permission is active and applicable)

Q: Is :Bob permitted to print :Asset1? A: n/a (no applicable permission)

Q: Is :Alice permitted to print :Asset2?
A: n/a (no applicable permission)

:policy202 a odrl:Set ;
    ### not active ###
    odrl:permission [
        odrl:target :Asset1 ;
        odrl:assignee :Alice ;  
        odrl:action odrl:print ;
        odrl:constraint [ 
            odrl:leftOperand odrl:dateTime;
            odrl:operator odrl:lt ;
            odrl:rightOperand "2000-12-31" ;
        ]
    ] .

Q: Is :Alice permitted to print :Asset1?
A: no or n/a (permission is applicable but not active)

Q: Is :Bob permitted to print :Asset1? A: n/a (no applicable permission)

Q: Is :Alice permitted to print :Asset2? A: n/a (no applicable permission)

:policy203 a odrl:Set ;
    ### active ###
    odrl:permission [
        odrl:target :Asset1 ;
        odrl:assignee :Alice ;  
        odrl:action odrl:print ;
    ] ;

    ### active ###
    odrl:prohibition [ 
        odrl:target :Asset2 ;
        odrl:assignee :Alice, :Bob ;
        odrl:action odrl:display ;
    ] .

Q: Is :Alice permitted to print :Asset1?
A: yes (permission is active and applicable)

Q: Is :Bob permitted to print :Asset1?
A: n/a (no applicable permission)

Q: Is :Alice permitted to display :Asset2?
A: no (prohibition is active and applicable)

Q: Is :Bob permitted to display :Asset2?
A: no (prohibition is active and applicable)

UC3: Conflict Detection/Resolution

http://w3c.github.io/poe/model/#conflict:

The conflict property is used to establish strategies to resolve conflicts that arise from the merging of Policies or conflicts between Permissions and Prohibitions in the same Policy.

Example:

:policy301 a odrl:Set ;
    ### active ###
    odrl:permission [
        odrl:target :Asset1 ;
        odrl:assignee :Alice ;  
        odrl:action odrl:print ;
    ] ;

    ### active ###
    odrl:prohibition [ 
        odrl:target :Asset1 ;
        odrl:assignee :Alice ;
        odrl:action odrl:print ;
    ] .

Q: Is :policy301 valid? A: no (both permission and prohibition are active, apply to the same assignee and asset, and are defined for the same action)

:policy302 a odrl:Set ;
    ### not active ###
    odrl:permission [
        odrl:target :Asset1 ;
        odrl:assignee :Alice ;  
        odrl:action odrl:print ;
        odrl:constraint [ 
            odrl:leftOperand odrl:dateTime;
            odrl:operator odrl:lt ;
            odrl:rightOperand "2000-12-31" ;
        ]
    ] ;

    ### active ###
    odrl:prohibition [ 
        odrl:target :Asset1 ;
        odrl:assignee :Alice ;
        odrl:action odrl:print ;
    ] .

Q: Is :policy302 valid? A: yes (both permission and prohibition are defined for the same action and apply to the same assignee and asset, but only the prohibition is active)

:policy303 a odrl:Set ;
    ### active ###
    odrl:permission [
        odrl:target :Asset1 ;
        odrl:assignee :Alice ;  
        odrl:action odrl:print ;
    ] ;

    ### active ###
    odrl:prohibition [ 
        odrl:target :Asset1 ;
        odrl:assignee :Bob ;
        odrl:action odrl:print ;
    ] .

Q: Is :policy303 valid? A: yes (both permission and prohibition are active, apply to the same asset, and are defined for the same action, but don't apply to the same assignee)

(more on that tomorrow)

nitmws commented 7 years ago

I agree to the considerations of @simonstey .

Simple example: policy102 in UC1 would be active if the rule is tested for printing on 24 December 2000. Simon made a hidden statement: the reference time for the evaluation is 2017-08-30T12:06:00+02:00 (the time he published the comment). I want to point at this often occurring media publishing use case: an article and photos are edited on 31 August for publishing them on 1 September. Therefore constraints must be matched against the 1 September and not the time of editing them.

I claim: without having set a reference value for each of the LeftOperands (requiring one - most of the ones in the Common vocabulary do so) of the constraints in a Rule it is impossible to evaluate even only the Active state of a Rule. (Aside: holding the reference value of the leftOperand is the job of the status property of a Constraint.)

Further: Rules can be evaluated without checking assignee and/or target - but this could result in useless Rule outcomes and will be considered as squandering time and effort.

What I would like to have in the ODRL Recommendation: For the evaluation of the Not-/Active state of a Rule:

the mandatory target should be included
the optional assignee should be included if it exists
the assigner may be included
all constraints must be included All of them have to be evaluated against reference values set by the Evaluator (and the party running it) for a specific evaluation.

Terminology note: the policies in UC3 we should not be tested for "is the policy valid" but "does the policy have conflicts"

nitmws commented 7 years ago

Re the evaluation of the Not-/Active state of Permissions:

The 2.6.8 in the IM of 29 August defines this workflow for evaluating Permissions:

all existing constraints must be evaluated (defined for all kinds of Rule)
this sets a first Not-/Active state (defined for all kinds of Rule)
then all existing duties are evaluated (defined for Permission only)
this sets a second, final Not-/Active state (defined for Permission only)
this final state is transformed directly - without any further evaluation - to the outcome of the Permission: Permission rule is not-/allowed

The step 5 is in fact useless, its a kind of renaming things only.

Therefore I suggest:

all existing constraints must be evaluated
this sets the Not-/Active state - the final one as for any other kind of Rule
then all existing duties are evaluated
this sets the outcome of the Permission: Not-/Ready-for-exercising (the name of the outcome may be discussed) This is in fact the same workflow as for Prohibition:Not-/Violated and Duty:Not-/Fulfilled.

I hope we can agree on that tomorrow.

riannella commented 7 years ago

@simonstey RE: UC2 I am trying to understand why you would ask "Is :Bob permitted to print :Asset1" when the Policy has nothing to do with Bob? It seems we want ODRL to "act" like a SPARQL endpoint and accept any query?

(Note: this does not mean you can't do that - anyone can put all their policies into a graph-db and SPARQL away...but it is not a normative requirement on the spec)

RE: UC3

We should update that section now that we have a better understanding of Rule "states". The Conflict section includes steps for "ODRL validation requirements" (that is, the first stage of "2.6.8 Rule Active State Processing")

Perhaps we should also move section 2.6.8 to 2.11 - so it is after the Conflict section and promoted to a higher level.

riannella commented 7 years ago

@nitmws Can you give a more detailed example of this:

I want to point at this often occurring media publishing use case: an article and photos are edited on 31 August for publishing them on 1 September. Therefore constraints must be matched against the 1 September and not the time of editing them.

Since dateTime will always compare dates to "right now".

riannella commented 7 years ago

@nitmws In your suggested 4 steps:

1 - Does this include this step: "Check if exercising the disallowed action of a Prohibition sets it to Violated" 2 - In the step "then all existing duties are evaluated " -> Some Duties don't need to be fulfilled, such as a consequence, if the duty is already fulfilled.

nitmws commented 7 years ago

@riannella re your "4 steps" issue above:

re 1 - these 4 steps were defined for the Permission Rule only as this is the only one with 2 Not-/Active states. (after checking the constraints and after checking the duties). The workflows for Prohibition and Duty stay unchanged as defined in 2.6.8 of 29 August.
re 2 - please check the casing of the terms: "... then all existing duties are evaluated ... " = I'm writing about the Duties related by the duty property of a Permission and not about Duties related by the consequence property of a Duty or about any other property of type Duty. I guess this explains my intention.

Btw: this Evaluation Workflow draft v5 explains my intentions too: https://docs.google.com/spreadsheets/d/1vej4EwEZjUM2yYJwBggJxHlSTCinyuMPCulKIeHNTA0/edit?usp=sharing

nitmws commented 7 years ago

@riannella re your "more detailed example" issue above: as it is outside the scope of 2.6.8 I've created a new issue #227

simonstey commented 7 years ago

RE: UC2 I am trying to understand why you would ask "Is :Bob permitted to print :Asset1" when the Policy has nothing to do with Bob? It seems we want ODRL to "act" like a SPARQL endpoint and accept any query?

This was mainly for illustrating that for scenarios like UC2 it's necessary to be able to assess both, whether a rule is active but also whether it's applicable for a given request.

Not all active rules are also applicable.

simonstey commented 7 years ago

@nitmws

I claim: without having set a reference value for each of the LeftOperands (requiring one - most of the ones in the Common vocabulary do so) of the constraints in a Rule it is impossible to evaluate even only the Active state of a Rule.

ODRL doesn't specify how constraints have to be evaluated.. and since the individual semantics of leftOperands are defined as natural language text only, you won't be able to achieve interoperability wrt. to constraint evaluation anyway.

Further: Rules can be evaluated without checking assignee and/or target - but this could result in useless Rule outcomes and will be considered as squandering time and effort.

?

the mandatory target should be included the optional assignee should be included if it exists the assigner may be included all constraints must be included All of them have to be evaluated against reference values set by the Evaluator (and the party running it) for a specific evaluation.

that's too restrictive, as it is only relevant for certain use cases.

Terminology note: the policies in UC3 we should not be tested for "is the policy valid" but "does the policy have conflicts"

http://w3c.github.io/poe/model/#conflict:

If an ODRL processor (sic!) does not detect any conflicts in the Rules, then the ODRL Policy is valid, otherwise the ODRL processor MUST follow these ODRL validation requirements:

If a Policy has the conflict property of perm then any conflicting Permission Rule MUST override the Prohibition Rule and continue with the Policy as valid.

=> so even though a policy might have conflicts, it can be valid

nitmws commented 7 years ago

Based on the call on 31 August and the statement that 2.6.8 must not indicate any sequence of processing the Active state and Duties I suggest to rephrase this section from the 2nd para on - see below.

But first I suggest to consider the heading Rule Active State Processing as this section covers now more than that. What about: Rule Active State and Further Processing

The heavily rephrased text - removing an evaluation sequence has a heavy impact on the phrasing, it has to cover all possible options. Revised version of 2017-09-01T09:39:00Z

An ODRL Evaluator MUST evaluate if a Rule is in the Active state and if other requirements have been met to determine the outcome of the Rule.

If a Rule has no constraint properties, then it is set to Active. If all constraint properties of a Rule are satisfied the Rule is set to Active, if at least one of the constraint properties is not satisfied, then the Rule is set to Non-Active.

To set the outcome state Ready-for-Exercising of a Permission, any existing duty property MUST be Fulfilled and the Permission MUST be Active. If at least one duty property is Not-Fulfilled the outcome state is set to Not-Ready-for-Exercising. If the Permission is Non-Active, regardless of the states of duty properties the Permission should be considered as not-existing, which means it should not be included in further evaluations.

For a Prohibition the Evaluator must check if its action was exercised:

If it has not been exercised and if the Prohibition is Active the outcome state is set to Not-Violated.
If the action has been exercised and no remedy properties exist and the Prohibition is Active its state is set to Violated.
If the action has been exercised and if remedy properties exist and if at least one of them is Not-Fulfilled and if the Prohibition is Active its state is set to Violated.
If the action has been exercised and if remedy properties exist and if all are Fulfilled and if the Prohibition is Active its state is set to Not-Violated.
If a Prohibition is Non-Active, regardless of the evaluation of its action and of any remedies the Prohibition should be considered as not-existing, which means it should not be exposed to further evaluations.

For a Duty the Evaluator must check if its action was exercised:

If it has been exercised and if the Duty is Active the outcome state is set to Fulfilled.
If the action has not been exercised and no consequence properties exists and if the Duty is Active its state is set to Not-Fulfilled.
If the action has not been exercised and consequence properties exist and if all are Fulfilled and if the Duty is Active its state is set to Fulfilled.
If the action has not been exercised and consequence properties exist and if at least one of them is Not-Fulfilled and if the Duty is Active its state is set to Not-Fulfilled.
If a Duty is Non-Active, regardless of the evaluation of its action and any consequences the Duty should be considered as not-existing, which means it should not be exposed to further evaluations.

nitmws commented 7 years ago

I noticed issues with open ended Not-Active states of the Rule Active State and Further Processing suggested above while updating the Evaluation Workflow table to version 6 (https://docs.google.com/spreadsheets/d/1vej4EwEZjUM2yYJwBggJxHlSTCinyuMPCulKIeHNTA0/edit?usp=sharing)

At the call on 31 August it was stated "2.6.8 MUST NOT define any processing sequence - the currently defined 'Not-/Active state first, then depending on it further processing' should be taken out"
As result I removed the sentence "A Non-Active Rule means that no further processing should be executed at this time and no outcomes can be determined from the Rule." from the rephrased version above.
Result: it is not clear what "a Rule is Not-Active" means.

For that reason I revise my suggestion above (in a few minutes) to solve that issue by adding the impact of the Not-Active state to each Duty subclass.

riannella commented 7 years ago

Ok, look forward to it !

(as a test, adding @benedictws to see if a notice is sent to him)

riannella commented 7 years ago

Changed "processing" to "validation" In Conflict section.

I updated the heading to just "Rule Processing"

"Ready-for-Exercising" and "Not-Ready-for-Exercising" are too cumbersome... Changed them to "Exercisable" and "Not-Exercisable"

I removed "not-existing" and just said stop evaluating.

The rest updated the rest as per @nitmws suggestion above

Please review :-)

riannella commented 7 years ago

Done some editing of this section for consistency. Moved the common Active requirement to the first part of each sub-section.

riannella commented 7 years ago

I have updated (and simplified) the Rule Processing section.

Please review the narrative and make explicit comments/feedback on the narrative.

Are all the states requirements correctly captured? If not, then please indicate the missing required text we need to add to the narrative.

Are the state requirements correctly described? If not, then please indicate the text we need to update in the narrative.

nitmws commented 7 years ago

I've got the feeling that members of this group have different views on the role of the Non-/Active state of Rules and I raised a clarification of that as new issue #245 as prerequisite for writing an agreed Rule Processing.

riannella commented 7 years ago

Another rewrite of the entire section

riannella commented 6 years ago

As agreed at today's call, section 2.6.8 will be removed and individual sections updated

http://www.w3.org/2017/09/11-poe-minutes.html

nitmws commented 6 years ago

Having a look at the draft Truth Tables of an ODRL Evaluator - https://www.w3.org/2016/poe/wiki/Evaluator - and on the IM of 9 September I see a need to write down some conclusions for getting the results shown in the the Truth Tables - I reference the current numbering of IM sections:

how the states "satisfied" and "not satisfied" are generated for a Constraint instance is defined by 2.5.1 - ok
the "constraint" property with a Rule is defined in 2.5.4. - I suggest to move it up one notch and make it 2.5.3 as the current 2.5.3 is about refinements and the following sections 2.5.5 and 2.5.6. too. This section on "constraint" is missing the impact of not/satisfied Constraints on a Rule - e.g.: If all Constraints referenced by constraint return "satisified" the Rule is active for further processing, if at least one of the referenced Constraints returns a "not satisfied" the Rule is not active for further processing. Note: this section could be felt as "applies to any Rule" and there is no need to mention this again in sections about a specific sub-class of Rule. But as constraints are so essential I suggest to mention it in the section about Permission, Prohibition and Duty.
Permission Class is defined in 2.6.1 but it does not mention the impact of constraint and duty - this may be added, e.g.: by appending to the first sentence "... an Asset if all constraints are "satisfied" and if all duties are "fulfilled". "
Prohibition Class is defined in 2.6.2 but it does not mention the impact of constraint and remedy - this may be added by inserting into the first sentence, e.g.: A Prohibition disallows an Action to be exercised on an Asset if all constraints are "satisfied" and defines optional remedies if it has been exercised. (I'm aware of the questions regarding the semantics of a Prohibition ...)
the "refinement" property of an action is defined in 2.5.3 and this section is missing the impact of not/satisfied Constraints - e.g.: If all Constraints referenced by refinement return "satisfied" then exercising the action will be effective on the Rule, if if at least one of the referenced Constraints returns a "not satisfied" the Action cannot be considered as exercised.
the "refinement" property of Collection is defined in 2.5.5 and 2.5.6. Both are vague about the impact of not/satisfied refinement Constraints: by applying refinement Constraints to the members of a Collection the number of members may be reduced - right? Note: this is quite high impact, e.g.: a Permission MUST have a target; a referenced AssetCollection may have 100 members without refinements. Then 3 refinements are applied - and the Collection has no member anymore. Is the Permission still valid?
Duty Class is defined in 2.6.3. but this section does not define how the state "fulfilled" is achieved. E.g.: A Duty is fulfilled if all constraints are "satisfied" and if its action has been exercised.
the "consequence" property is defined in 2.6.3. and in 2.6.6. The heading of the 2.6.6 section insinuates "consequence" properties may be used only with Duties of a Permission - but also a Duty referenced by "obligation" may use it! I suggest to rename the heading to "Consequence property with a Permission or an Obligation Duty" and to include both options in the 1st paragraph. (It is ok to have an example covering only a Permission Duty.) The definition of the conclusions from not-fulfilled Duties and that consequences becoming active is currently misleading as it is selfreferential: if the parenting Duty has not been fulfilled it does not make sense to require that both the parental Duty and the consequence is fulfilled. Alternative wording: If either of these fails to be fulfilled, then all Duties referenced by the consequence property must be fulfilled to change the state of the obligation Duty or the duty Duty to fulfilled, if at least one of the consequences is not fulfilled the obligation Duty or the duty Duty stay as not fulfilled. If either of these fails to be fulfilled and no consequence exists the state of the obligation Duty or the duty Duty cannot be changed.
the "remedy" property is defined in 2.6.7. Only a minor wording issue in the existing language and the result of fulfilling the remedies is missing: If the Prohibition action is exercised, then all remedy Duties MUST be fulfilled to let the Prohibition be considered as not violated. If at least one remedy Duty is not fulfilled the Prohibition is to be considered as violated. (I'm aware of the questions regarding the semantics of a Prohibition ...)

riannella commented 6 years ago

Thanks @nitmws - I am slightly confused by your comments in bullet point 8. Are you saying that a consequence AND duty must NOT both be fulfilled (if the duty has not been fulfilled) - only the consequence?

riannella commented 6 years ago

I have removed section 2.6.8 and moved normative statements back into the other sections.

Please review carefully and provide any explicit changes (eg swap "blaa blaa" with "foo foo" in para x of section y)

I have not included any wording that would imply any form of "processing rules".

If there is a need for implementors to describe "states" then the terms in the IM could be used: Permission: "exercisable" or "not exercisable" Prohibition: "not-infringed" or "infringed" Obligation: "fulfilled" or "not-fulfilled"

riannella commented 6 years ago

@nitmws re: bullet#6

If a refinement, such as example 16 in the IM, results in no individual asset (ie: there are only movies > 60 mins in the Collection) then the Constraint is "not satisfied" ?

nitmws commented 6 years ago

@riannella reply to "I'm slightly confused" above: The problem of the wording of this section is that is has to cover 2 steps of the evaluation:

A Duty has evaluation rules without considering consequences: all constraints are satisfied and the action is exercised --> fulfilled, if the action is not exercised: not fulfilled. I call this "evaluation step 1" below.
But that's not the end of the evaluation of a Duty currently in a not-fulfilled state:
- if conseqence(s) exist it/they must be evaluated
- if all are fulfilled the state of the Duty is changed from not-fulfilled to fulfilled

The wording, also in the version of today (12 September), sounds like: both results, the one of the evaluation step 1 and the other one of the consequences, must be "fulfilled". But as consequences have only to be evaluated if the evaluation step 1 result is not-fulfilled this is a contradiction.

I suggest this wording, based on the IM of 12 September:

there is also the obligation missing at the end of the first sentence.
the statement "or the Permission exercised without fulfilling the duty" is new. By what has been discussed so far a consequence applies only to not-fulfilling a Duty instance and not to a parenting Rule.

A duty of a Permission, and obligation of a Policy, may include a consequence Duty of not fulfilling that duty or obligation. In this case all consequence Duties must be fulfilled to set the final state of the Duty to fulfilled.

nitmws commented 6 years ago

re @riannella on bullet #6 (I've modified the list from bullet points to numbers now)

Ok, but what is the result of a "not-satisfied" refinement Constraint on its AssetCollection? By the generic rules regarding the use of Constraint the Thing referencing it turns into being not-active. And a Permission (in example 16) MUST have a target - but in this case it doesn't.

nitmws commented 6 years ago

A first review of spreading the content of section 2.6.8 to corresponding sections:

I like the basic approach: the definition of a class covers

the impact of values of properties on the evaluation of a class
a final result from evaluating this class

A wide wording issue: the IM must make a strict distinction between a class and a property - in particular if their name uses the same characters and the only difference is the casing, e.g. Duty vs duty. And: values of the evaluation of a class are returned into a class referencing them by properties, therefore the lowercase property name should be used:

in 2.6.1: A Permission allows an action to be exercised on an Asset if all constraints are satisfied and if all duties are fulfilled
in 2.6.2: A Prohibition disallows an action to be exercised on an Asset if all constraints are satisfied. If the Prohibition has been infringed by the action being exercised, then all of the remedies must be fulfilled.
in 2.6.3: A Duty is the obligation to exercise an action. A Duty is fulfilled if all constraints are satisfied and if its action has been exercised.
in 2.6.4: A Policy MAY include an obligation to fulfil a Duty. The obligation is fulfilled if all constraints are satisfied and if its action has been exercised.

(End of review part 1, more will follow later)

nitmws commented 6 years ago

Review part 2:

Some details, my suggested changes in bold:

2.6.2 : That is, the remedy property asserts a Duty that must be fulfilled if the action of the Prohibition is exercised
2.6.3: the Duty class definition is missing the role of consequence - which should be done similar to the Prohibition class. Add: If its action has not been exercised all consequences must be fulfilled to fulfil the Duty. (Note: only Duties referenced by duty or obligation properties may use consequence properties.)
2.6.3: the definition of the consequence property swaps subject and object of the triple: A Duty MAY have none, one or many consequence property values of type Duty only when the Duty is referenced by a Rule with the duty or obligation properties.

Re @riannella 's statement about describing "states": As I said in part 1 the IM defines that instances of the Rule sub-classes return a value: a e.g. constraint property of the Rule Class is defined as "A Rule MAY have none, one or many constraint property values of type ..." and this raises the question: what is the value of the referenced instance of the xxx Class? This applies to the Permission, Prohibition and Duty Class as they are referenced with a property by different "parenting" classes. To define specific names for returned values representing a state of the referenced class makes sense to me, makes the reading, keeping track and understanding easier.

riannella commented 6 years ago

1 - updated first para of "Consequence property with a Permission/Obligation Duty" section as per above.

2 - added notes that "refinement" must not result in null/empty outcomes

3 - Part 1 Review changes done

4 - Part 2 Review changes done

@nitmws In the bottom part of "Review Part 2" - are you asking for a change to some narrative?

nitmws commented 6 years ago

re 2 above: I'm afraid that "must not" doesn't work. See example 16: the AssetCollection is defined in a persistent way but its members may change on a hourly base (or even shorter) - and ODRL doesn't have any influence on that. I suggest to add to the definitions of both Collections: "As a result of applying refinements to a ...Collection it may not include any members but this does not make to the ...Collection invalid." ... the Rule has only a target or assignee with no members. That may be not nice for the assignee but this has no (negative) formal impact on the rights expression.

Re "some narrative": reading the latest wording I think only the Prohibition needs some added narrative:

Permission Class: looks ok, tells what allows to take its action - and what not.
Prohibition Class: a statement about what is the impact of fulfilled remedies on the "infringed" state is missing. e.g. "... must be fulfilled, in this case the the Prohibition is not infringed {anymore}."
Duty Class: looks ok, tells what fulfils it - and what not.
Constraint/Logic Constraint Classes: look ok, describes what satisfies a Constraint and what not - could we set "satisified" and "not satisifed" in bold as it is done for the keywords in the classes above?

By that - and by my view - the final state of an evaluation of a Rule sub-class could be expressed by a single term as listed by @riannella above in https://github.com/w3c/poe/issues/226#issuecomment-328742047 which definitely helps with the Truth Tables of the Evaluator. Agreed?

riannella commented 6 years ago

But....if you look at Example 16 at https://w3c.github.io/poe/model/#constraint-party If the result of the refinement is a null set of Parties, then the Agreement has no assignee, which means is is not a valid agreement?

Clearly this not in the control of ODRL (another Black Box) but we need to at least have note so implementors are aware that this result may occur and they may need to do something. (same idea as "uid" being a should, not a must for assets/parties).

How about:

Note: If the outcome of applying refinements to a PartyCollection result in a null set, then the full implications must be understood, such as the impact on ODRL Validators of ODRL Policies.

Other changes (as above) made.

Hope others agree to the agreed part ;-)

nitmws commented 6 years ago

re @riannella above: a state of zero members of a Collection SHOULD NOT make it invalid.

Another practical example: a Permission grants access to service ABC to the group of 50 to 60 year old people in a community (= PartyCollection). If today nobody of this age is member of the community then simply today nobody has access to service ABC. But this will cause no problems for the assigner and the "general" assignee, the community as a whole.

To be strict on that: an ODRL Validator MUST NOT check the number of members of a Collection, it may only check if the class related by e.g. the assignee property is a Party or PartCollection, or something else and only that makes the Rule invalid.

Therefore I like the result "null set" in the suggested note as it defines that this xCollection is a valid set but at the moment of this evaluation it contains no element (in set terminology).

Therefore I suggest to stop the note above after ".... understood ." as no-members has no formal impact on validity, maybe only on the business (as there is nothing to be used or nobody to be addressed).

riannella commented 6 years ago

done

nitmws commented 6 years ago

Similar issue in 2.5.4 - Note: a refinement property MUST not narrow the semantics of the Action to a null operation.

I suggest to downgrade the requirement to "SHOULD NOT narrow" as e.g. a compensation action with a refinement of "pay 0 (zero) Quids" is not invalid, it only looks a bit strange.

riannella commented 6 years ago

Done. I added SHOULD NOT to the other two as well.

(SHOULD NOT also implies "but the full implications should be understood and" as per RFC2119)

w3c / poe