Permissions and Obligations Expression Working Group Teleconference

<scribe> scribe: michaelS

<scribe> scribenick: michaelS

approve last meeting minutes

<renato> https://www.w3.org/2016/12/12-poe-minutes.html

<Serena> +1

renato: any updates or comments?

+1

RESOLUTION: Minutes of 12/12/16 approved

scribe: hearing not comments

RESOLUTION: minutes accepted

issues needing a WG Decision

<renato> https://github.com/w3c/poe/labels/Needs%20WG%20Decision

<phila> Issue 84

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

First issue #84

https://github.com/w3c/poe/issues/84

renato: outlined the change: creating a new explicit leftOperand property taking the name of the constraint
... this makes the structure quite clear

phila: seems clear. does this solve the relative times use case?

renato: sorry, but it doesn't

benws: is that a kind of ontoloy housekeeping

renato: the current way of expressing is not wrong but not easy to follow. The change makes things clearer

phila: Worries about the relationship "constraint" leading to "Constraint" - he is not perfect as some langauges has not upper/lower case script

renato: "has constraint" is the human readable label

<renato> http://w3c.github.io/poe/vocab/#term-constraint

phila: agrees to this workaround but would be happier about an explicit property id

benws: having 2 URIs for the same property?

phila: yes

renato: not happy about having two properties for the same use

phila: would deprecate "constraint" and create "hasConstraint"

<simonstey> +q

<Zakim> phila, you wanted to go on about i18n

simonstey: didn't we have the same discussion about other properties? Does not like having "has..." and "..." properties

renato: after the Lisbon meeting some properties got a "has" prefixed to the label
... any objections to the proposal of #84?
... hearing none concluded that is agreed

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

renato: issue 82
... outlined the change: this proposal allows to have a party or asset also at the Policy level, both apply to any rule of this policy

be

benws: what if party/asset exist at the Policy and the Rule level

renato: this would be an invalid use

benws: multiple uses would be useful

renato: a mix of parties and assets not of help

smyles: is this a change to the information model

renato: it is a change to the model but not a significant one

smyles: is this only a change of the syntax only

benws: not a change, improves the precision

<simonstey> Party: the Permission MAY refer to one or more Party entities linked via the Role entity (OPTIONAL)

simonstey: doesn't see the need for making a policy wiht party/asset at Policy and Rule level invalid
... if we stick to that we need to reword the specification

James: we opted for having a flexible set of permissions/prohibitions

michaelS: having party/asset at both levels would make users using both - not reading the free-text specs

phila: would it reduce the problme to use an explicit "inherit" in Rules indicating that the value of the Policy level should be used

<James> +1

<Serena> +1

benws: I like the feature, in 99% of the cases only the policy level would be used. We should decide either "union" or "overwrite"

<Serena> +1 for overwriting

renato: Option 1: a party/asset in a Rule overwrites party/asset of the Policy level

phila: the information model should include a test including this feature

<simonstey> fwiw, https://www.w3.org/2016/poe/wiki/Requirements#POE.R.R_Processing_Rules

<simonstey> +q

Sabrina: pointed at the conflict resolution of ODRL. The more generic should take precedence over more specific

simonstey: this conflict resolution does not define (yet) anything for assets and parties, this needs to be explicitly added
... we should think of the use case of having party/asset in a parent policy, how are they inherited in a child policy?

renato: agreed that this feature of policy inheritance was not reviewed yet
... current options: keep it as it is or adding party/asset to the policy level with an "overwrite" rule

<simonstey> +q

<Zakim> phila, you wanted to talk about https://www.w3.org/TR/powder-dr/#powderprocessor as an example

benws: renato and Serena shoudl have a look at the policy inheritance first

phila: pointed a the Powder Processor - the work on that ended with a section of rules for making software conformant.

<simonstey> The Child Policy MUST override the Parent Policy. i.e.: If the same Action appears in the Parent, then it is replaced by the Child version, otherwise the Parent Actions are added to the Child’s Actions.

simonstey: pointed at overly compex rules in the context of policy inheritance - the ODRL specs should not go in this direction

renato: inheritance was understood well in the ODRL 2.1 (and earlier) wordl

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

renato: Issue #73
... outlined the change: this change allows to have multiple actions per rule
... e.g. distributed, printed and more in the same rule

<simonstey> +q

renato: in fact a shortcut of many rules with only different actions

benws: likes this change.
... this could speed up the processing.

simonstey: felt that this could have been done already by users not reading the specs :-(

<Sabrina> +q

simonstey: but are a list of rules and the same combined into one semantically the same.
... in this case that must be defined explicitly.

<Serena> * we should check carefully inheritance in this case too *

<victor> +1

benws: Can we apply the same logic to assets = having multiple in a rule?

renato: could be ...

<victor> I would handle assets in the same manner, using the same logic.

<Sabrina> +q

benws: suggest to have a look at both

renato: agreed.

Sabrina: shouldn't that apply to parties too?

renato: yes, but already yet multiply parties may be assigned to a single rule

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

renato: Issue #72
... outlined the change: return to the original approach of "odrl-vocab"

<Sabrina> +1

<victor> +1

<Serena> +1

<smyles> +1

<renato> +1

<James> +1

<renato> Proposal: change vocab short name to "odrl-vocab"

<simonstey> +1

<Sabrina> +1

<Serena> +1

<smyles> +1

RESOLUTION: change vocab short name to "odrl-vocab"

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

Issue #48

issue #48

issue #48

renato: invited group members to have a look at that issue and to submit comments

<simonstey> +1

<simonstey> -1

<simonstey> +q

simonstey: How does this differ from constraints

renato: this is not about constraints but provides information about the policy document

<victor> Just to say that I would also add authorship and license itself.

benws: new topic: wants to see constraints on constraints examples

renato: let's put it on the agenda for the next call

<James> Thanks

renato: next call next week