Closed simonstey closed 6 years ago
I've written down similar issues in https://lists.w3.org/Archives/Public/public-poe-wg/2017Aug/0012.html
Updated the Rule Active State Processing based on this feedback. Also changed "odrl processing" to "odrl validation" in other sections
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 :
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.
I've updated the draft of an ODRL Evaluation Workflow to version 4, see https://docs.google.com/spreadsheets/d/1vej4EwEZjUM2yYJwBggJxHlSTCinyuMPCulKIeHNTA0/edit?usp=sharing
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?
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:
https://www.w3.org/2016/poe/wiki/Evaluator:
The task of an ODRL Evaluator is to determine which
Permission(s) or ProhibitionsRules 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" ;
]
] .
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)
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)
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:
Terminology note: the policies in UC3 we should not be tested for "is the policy valid" but "does the policy have conflicts"
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:
The step 5 is in fact useless, its a kind of renaming things only.
Therefore I suggest:
I hope we can agree on that tomorrow.
@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.
@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".
@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.
@riannella re your "4 steps" issue above:
Btw: this Evaluation Workflow draft v5 explains my intentions too: https://docs.google.com/spreadsheets/d/1vej4EwEZjUM2yYJwBggJxHlSTCinyuMPCulKIeHNTA0/edit?usp=sharing
@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
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.
@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
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:
For a Duty the Evaluator must check if its action was exercised:
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)
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.
Ok, look forward to it !
(as a test, adding @benedictws to see if a notice is sent to him)
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 :-)
Done some editing of this section for consistency. Moved the common Active requirement to the first part of each sub-section.
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.
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.
Another rewrite of the entire section
As agreed at today's call, section 2.6.8 will be removed and individual sections updated
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:
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?
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"
@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" ?
@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:
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:
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.
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.
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
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:
(End of review part 1, more will follow later)
Review part 2:
Some details, my suggested changes in bold:
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.
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?
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:
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?
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 ;-)
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).
done
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.
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)
what's an ODRL processor? we only define ODRL validator and ODRL evaluator in the Terminology.
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.
and after that? what's 2nd?
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
https://www.w3.org/TR/shacl/#shapesGraphWellFormed
This part should be replaced/updated, reflecting @nitmws recently suggested interpretation: