Permissions and Obligations Expression Working Group Teleconference

<renato> victor/linda - will u join the teleconf call?

I can scribe if nobody does

<scribe> scribe: victor

<renato> https://www.w3.org/2017/08/07-poe-minutes

approve last meeting minutes

decision: approve last meeting minutes

<renato> https://github.com/w3c/poe/projects/1

RESOLUTION: approve last meeting minutes

github issues

<renato> https://github.com/w3c/poe/issues/209

subtopic: Consequence/Remedy, issue 209

renato: there has been a first proposal (2 weeks ago) and a second one (1 week ago)
... https://www.w3.org/2016/poe/wiki/Duty_Relations

simon: it is faster to talk than to speak
... failure is more general and there may be ambiguity
... the fact that there is a permission with a non-fulfilled constraint does not imply that there is a prohibition on that permission
... it is a owa/cwa
... the verification of chain of implies requires verifying not only not the existence of prohibitions but also the existence of permissions whose constraints are not satisfied

sabrina sees a difference between remedy and consequence

<renato> victor: spec worded as follows:

Constraints must be checked by processings system at the time of executing the relevant action. If the constraint is satisfied (ie the logical expression is true) then the action becomes valid for the enclosing Rule. If the constraint is not satisfied, then the action is not valid for the enclosing Rule.

<simonstey> +q

<renato> victor: agree on diff between conseq/remedy

<simonstey> "For a Rule to become effective, all of it's Constraints MUST be satisfied and any applicable relationship to a Duty MUST be fulfilled."

simon: the term "valid" is confusing to me.

<renato> https://w3c.github.io/poe/model/

renato: failure as a superproperty of consequence and remedy

victor: if a permission has a constraint a failure, then the rule fire upon failure becomes in effect.

simon: this means an addition verification to be done

victor: yes, an additional verification is needed. we need generality

simon: yes, this is not incompatible

benws: the current wording of (??) is now unclear

<renato> https://w3c.github.io/poe/model/#duty-policy

victor: I wished I could represent Prohibition(failed)-->permission, Prohibition(failed)-->obligation, Prohibition(failed)-->Prohibition2, every possible combination

benws: the difference between remedies and consequences can be better stated in that section

victor: (example with matrix of 3x3)

simon: i agree with a superproperty, but we leave it to custom implementations.
... we can leave failure as rule-to-rule property, whereas remedy and consequence as kept more precise.

renato: consequence and remedy remain as they are, failure is introduced as a property from rule to rule.

linda_b: this has to be well explained to non-technical users

RESOLUTION: integrate the agreement reached today

renato: this was the last issue before closing a version

Moving toward CR

benws: (shows screen with a matrix) The evaluator needs to make checks as those shown in the screen

simon: (explains an example)
... someone fulfills a duty (payment), having permission to download a dataset during 2017
... in 2018, the duty is fulfilled but the constraint is not

benws: interpretation is not so evident: is the rule in effect?

simon: it is not

benws: ok
... Example 16

simon: the consequence is not triggered in this example

benws: but the evaluator does not understand the constraints in the duty

ping

benws: Example 17

<renato> (we are still speaking?)

benws: we have now two duties
... etc. etc.
... IMPORTANT: is this what we expect from an evaluation?

victor: yes

simon: +1
... in addition, evaluators have to deal with conflicts, etc.

benws: we have (or will have) examples with conflicts
... given the set of columns (marks a column in the screen)... is the permission in effect or not?
... If you believe I am doing well, I will continue with this job.

renato: any comment?

(silence)

renato: please Ben, go ahead
... what else would be needed to go towards CR?

ivan: are we clear on how implementations will be done?

renato: every implementor will say "this is conformant because it passes A, B, C..."

<simonstey> earl!

ivan: there is no practical support at W3C to help with the conformance tests.

simon: the benefit of earl is manifested when there are many implementors
... not practical for a handful of implementors

ivan: we need implementations not coming from academic institutions

<renato> https://w3c.github.io/test-results/annotation-model/all.html

<simonstey> +q

<simonstey> http://w3c.github.io/data-shapes/data-shapes-test-suite/

renato: is that table created manually or automatically?

ivan: somebody must be responsible for compiling that

<simonstey> -q

benws: we have to focus on the ODRL interoperability layer, whereas the actual interpretation of constraints is domain specific.

<simonstey> +q

ivan: understand. some partners produce their own policies that others should be able to undestand. I wonder about INRIA (for example) producing policies ... till what extend do they have to be understood?

benws: the core model is slim

ivan: even if using a profile, the core of the policy should be understood (if it is valid)

benws: the disctinction between validating and evaluating is there: anybody can validate anything, evaluate requires knowing the meaning of constraints and duties

simonstey: we can check validity, yes.
... we want to find inconsistencies, etc.

<simonstey> https://github.com/simonstey/ODRL-SHACL-Shapes/wiki/SHACL-Shapes-for-validating-ODRL-Policies

ivan: you will have SHACL validators for S+

simonste: the wiki shows some examples of shapes

ivan: this should be part of the CR

renato: ben will have a lot of work to have the tables ready
... comments in github will be appreciated

benws: I will write updates on the wiki

renato: AOB?
... i hope we have next week an almost closed version