See also: IRC log
<renato> https://www.w3.org/2016/poe/wiki/Meetings
<michaelS> scribe: Sabrina
<michaelS> scribenick: Sabrina
<ivan> scribenick: Sabrina
Ben: any issues with last weeks minutes
<renato> https://github.com/w3c/poe/projects/1
RESOLUTION: minutes from last week passed
<renato> https://github.com/w3c/poe/issues/211
Ben: Can you provide an updated on issue 211
Simon: Everyone does not have the same
understanding of the term effective
... for a rule to be effective (i.e. become valid) all the conditions
must be satisfied
... for me effective means valid (i.e. it is here)
... e.g. a permission that is only valid for a timeframe
Ben: An assignee can only be bound by a condition that is ineffect
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
... this is not the same as ineffect
... If a duty is not ineffect then you don't need to do anything
... take for example a datetime constraint and one that defines an
amount to be paid
... there are two different semantics here - datetime is used for
ineffect and payAmount is used for fulfilment
Renato: I think every constraint has different semantics
Simon: The important part is the effect of
the constraint
... Ineffect constraints are not the same as duty constraints
Michael: I share Simons view and believe we should not use ineffect...
Simon: Duty inherits from rule and thus you can not use datetime constraints in the in effect sense
Ben: Can we express these now
Simon: On the policy level no
... the current spec with two different types of constraints on duties
is inconsistent
Ben: I had some challenges coming up with what is in effect and what isn't when I was preparing the test cases
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
... a rule is only effective if all the constraints are satisfied. If
you have a paya mount and a datatime according to the spec if you don't
have a pay amount amount then it is not in effect
Michael: A duty is a combination of an
action and a constraint
... the two have to be taken together
Simon: Duty as subclass of rule, it behaves like it is defined in the rule, whereby the constraint narrows down the rule
Michael: In a permission you may take this
action whereas a duty has to be fulfilled
... the permissions opens the door for a future action, however the
action of the duty has to be taken immediately
Simon: According to the spec: if the
constraint is not satisfied the duty is not in effect
... we need to explain how the constraints in duties are different to
constraints in rules
... and we eliminate the use of datetime in other rules
Ben: It seems strange that duties that are
also rules are different to other rules: a duty is always assumed to be
ineffect
... all other rules can either be ineffect or not
Renato: That is correct a duty has to be fulfilled to know if the permission is ineffect
Simon: Duties are always in effect...
... we have a duty pointed to by a permissions and a duty pointed to by
obligation
Michael: If the duty of a permission is not
fulfilled the permission is not in effect
... If an obligation is not fulfilled, what happens then
... an example is the GDPR
... if you don't do something there is a consequence
<benws_> linda-B present+
Sabrina and Michel have a discussion on requirements coming from regulations
Simon: There is no reason why an obligation
on the policy level would confuse people, deontic concepts are common in
policies
... we can have an agreement policy whereby sabrina agrees to pay 5
euros
Renato: If Sabrina does not pay then what would you call this?
Simon: We are in a conflict situation
Renato: I don't think it is a conflict, it just has not been done yet
Simon: in ODRL we don't say anything about when a constraint is due
Renato: True, but if you have a datetime constraint then can add it
Simon: I can, but I don't know how to handle these two different constraints
Michael: If the constraints are not satisfied then the duty has not been fulfilled
Simon: In one case, If I want to execute a permission, I check if the duties are fulfilled
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
Ben: Buying access to a dataset, pay 500
euro, per calendar month
... on the 12th of the month, I have not paid my subscription?
... what Simon is saying is that permission is still in effect even
though I have not paid this months fee yet
Simon: Yes, this is what I am saying
... the spec is inconsistent as we have both ineffect and fulfilled
... there used to be a set of duty constraints for checking fulfilment
... the current spec is not clear, this needs to be rectified
Ben: this does need to be resolved, looking
at truth tables also highlights there is an issue
... the subscription example is a good one
... we should park the subject for now
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
... if we don't solve the issue within one or two days we will not meet
the deadlines....
... we should look at the table that Ben produced, however we need an
extra call to resolve this issue
Ben: We should have a call on Thursday as this will give us time to review
Michael: What about meeting earlier 12:30 CEST (2 hours earlier)
Linda: This is an important issue, for
perspective users to implement
... if the working group can't see it clearly then how can the spec
users be expected to understand
<benws_> https://www.w3.org/2016/poe/wiki/Evaluator
Ben: Very briefly, I did write a draft of
the evaluator
... this issue bubbled up when I was writing it
... we need to check if the language is clear, have we covered all the
issues and did I get it correct
... any other issues
<ivan> trackbot, end telcon