12:15:24 RRSAgent has joined #poe 12:15:24 logging to http://www.w3.org/2017/08/21-poe-irc 12:15:26 RRSAgent, make logs public 12:15:26 Zakim has joined #poe 12:15:28 Meeting: Permissions and Obligations Expression Working Group Teleconference 12:15:28 Date: 21 August 2017 12:15:37 Agenda: https://www.w3.org/2016/poe/wiki/Meetings:Telecon20170821 12:18:21 Regrets+ Caroline 12:18:36 Chair: Ben 12:18:41 Regrets+ Victor 12:19:08 renato has joined #poe 12:20:17 present+ 12:25:46 present+ 12:31:47 michaelS has joined #poe 12:32:23 benws_ has joined #poe 12:32:37 present+ 12:32:57 present+ 12:35:56 Sabrina has joined #POE 12:36:14 present+ sabrina 12:36:21 simonstey has joined #poe 12:39:02 https://www.w3.org/2016/poe/wiki/Meetings 12:40:33 scribe: Sabrina 12:40:39 scribenick: Sabrina 12:40:40 scribenick: Sabrina 12:40:42 Ben: any issues with last weeks minutes 12:40:49 https://github.com/w3c/poe/projects/1 12:40:55 resolution: minutes from last week passed 12:40:59 https://github.com/w3c/poe/issues/211 12:41:12 Topic: last GH issue 12:41:14 Ben: Can you provide an updated on issue 211 12:41:34 Simon: Everyone does not have the same understanding of the term effective 12:41:41 present+ simonstey 12:42:11 ... for a rule to be effective (i.e. become valid) all the conditions must be satisfied 12:42:27 ... for me effective means valid (i.e. it is here) 12:43:11 ... e.g. a permission that is only valid for a timeframe 12:43:40 Ben: An assignee can only be bound by a condition that is ineffect 12:44:37 Simon: The issue is that constraints are used to define new business rules and we used them to determine when a duty is considered to be fulfilled 12:44:49 ... this is not the same as ineffect 12:45:10 ... If a duty is not ineffect then you don't need to do anything 12:45:39 ... take for example a datetime constraint and one that defines an amount to be paid 12:46:39 ... there are two different semantics here - datetime is used for ineffect and payAmount is used for fulfilment 12:47:12 present+ Linda 12:47:16 Renato: I think every constraint has different semantics 12:47:34 Simon: The important part is the effect of the constraint 12:47:48 Linda_B has joined #poe 12:48:35 Simon: Ineffect constraints are not the same as duty constraints 12:49:15 Michael: I share Simons view and believe we should not use ineffect... 12:50:37 Simon: Duty inherits from rule and thus you can not use datetime constraints in the ineffect sense 12:50:52 Ben: Can we express these now 12:51:19 Simon: On the policy level no 12:51:54 ... the current spec with two different types of constraints on duties is inconsistent 12:52:26 Ben: I have some challenges coming up with what is ineffect and what isn't when I was preparing the test cases 12:52:47 s/have/had/ 12:53:45 q+ 12:54:37 Simon: We don't have different types of duties e.g. duties, remedies, consequences we just have duties and the property is different for the type of duty 12:55:39 ... a rule is only effective if all the constraints are satisfied. If you have a payamount and a datatime according to the spec if you don't have a payamount amount then it is not in effect 12:56:00 Michael: A duty is a combination of an action and a constraint 12:56:20 ... the two have to be taken together 12:57:00 Simon: Duty as subclass of rule, it behaves like it is defined in the rule, whereby the constraint narrows down the rule 12:57:31 Michael: In a permission you may take this action whereas a duty has to be fulfilled 12:58:12 ... the permissions opens the door for a future action, however the action of the duty has to be taken immediately 12:59:25 Simon: According to the spec: if the constraint is not satisfied the duty is not in effect 12:59:48 ... we need to explain how the constraints in duties are different to constraints in rules 13:00:22 ... and we eliminate the use of datetime in other rules 13:00:54 Ben: It seems strange that duties that are also rules are different to other rules: a duty is always assumed to be ineffect 13:01:07 ... all other rules can either be ineffect or not 13:01:38 Renato: That is correct a duty has to be fulfilled to know if the permission is ineffect 13:02:09 Simon: Duties are always in effect... 13:03:11 ... we have a duty pointed to by a permissions and a duty pointed to by obligation 13:03:31 Michael: If the duty of a permission is not fulfilled the permission is not in effect 13:03:50 ... If an obligation is not fulfilled, what happens then 13:04:10 ... an example is the GDPR 13:04:25 ... if you don't do something there is a consequence 13:06:26 linda-B has joined #poe 13:06:50 linda-B present+ 13:07:01 linda-b_ has joined #poe 13:07:38 q? 13:07:43 ack m 13:09:38 Sabrina and Michel have a discussion on requirements coming from regulations 13:10:22 Simon: There is no reason why an obligation on the policy level would confuse people, deontic concepts are common in policies 13:11:03 ... we can have an agreement policy whereby sabrina agrees to pay 5 euros 13:11:27 Renato: If Sabrina does not pay then what would you call this? 13:11:51 Simon: We are in a conflict situation 13:12:11 Renato: I don't think it is a conflict, it just has not been done yet 13:12:44 Simon: in ODRL we don't say anything about when a constraint is due 13:13:16 Renato: True, but if you have a datetime constraint then can add it 13:14:19 Simon: I can, but I don't know how to handle these two different constraints 13:14:55 Michael: If the constraints are not satisfied then the duty has not been fulfilled 13:15:50 Simon: In one case, If I want to execute a permission, I check if the duties are fulfilled 13:16:50 In the case where you have a datetime, on a policy level, in 2017 you have to pay me and 2018 you do not, I can not express this 13:17:24 Ben: Buying access to a dataset, pay 500 euro, per calendar month 13:17:41 ... on the 12th of the month, I have not paid my subscription? 13:18:21 ... what Simon is saying is that permission is still in effect even though I have not paid this months fee yet 13:18:37 Simon: Yes, this is what I am saying 13:19:09 ... the spec is inconsistent as we have both ineffect and fulfilled 13:20:05 ... there used to be a set of duty constraints for checking fulfilment 13:20:57 ... the current spec is not clear, this needs to be rectified 13:21:31 Ben: this does need to be resolved, looking at truth tables also highlights there is an issue 13:21:46 ... the subscription example is a good one 13:22:03 q+ 13:22:07 ... we should park the subject for now 13:22:57 Ivan: When do we plan to resolve this? It is scary there are fundamental issues that have not been resolved 2 weeks before we go for CR 13:23:23 ... if we don't solve the issue within one or two days we will not meet the deadlines.... 13:23:54 ... we should look at the table that Ben produced, however we need an extra call to resolve this issue 13:24:17 Ben: We should have a call on Thursday as this will give us time to review 13:25:03 Michael: What about meeting earlier 12:30 CEST (2 hours earlier) 13:25:38 Linda: This is an important issue, for perspective users to implement 13:26:10 ... if the working group can't see it clearly then how can the spec users be expected to understand 13:28:34 https://www.w3.org/2016/poe/wiki/Evaluator 13:28:40 Topic: evaluator table 13:28:45 Ben: Very briefly, I did write a draft of the evaluator 13:28:59 ... this issue bubbled up when I was writing it 13:29:26 ... we need to check if the language is clear, have we covered all the issues and did I get it correct 13:29:39 Ben: any other issues 13:30:05 rrsagent, draft minutes 13:30:05 I have made the request to generate http://www.w3.org/2017/08/21-poe-minutes.html ivan 13:30:32 trackbot, end telcon 13:30:32 Zakim, list attendees 13:30:32 As of this point the attendees have been renato, ivan, benws_, michaelS, sabrina, simonstey, Linda 13:30:40 RRSAgent, please draft minutes 13:30:40 I have made the request to generate http://www.w3.org/2017/08/21-poe-minutes.html trackbot 13:30:41 RRSAgent, bye 13:30:41 I see no action items