Permissions and Obligations Expression Working Group Teleconference
08 May 2017
<renato> https://www.w3.org/2017/04/24-poe-minutes
Proposed: Accept minutes of 24 April https://www.w3.org/2017/04/24-poe-minutes
<michaelS> +11
Resolved: Accepted minutes of 24 April https://www.w3.org/2017/04/24-poe-minutes
renato: Need to discuss some of the GH issues
… We have had some reviews
… Next week is the F2F on Thursday/Friday so we need to look at the agenda
… Shouldn't forget about our Notes
… I'm assuming that we won't have a Monday call as we're meeting at the end of the week
<victor> ..anyway Monday is a day-off in Madrid.
renato: We had progress on wide review
… i18n have asked for another week.
… Not expecting any show stoppers
<renato> https://lists.w3.org/Archives/Public/public-poe-comments/2017Apr/
renato: Had some feedback...
… Comments from Antoine Isaac and Lars Svensson
renato: I've added those comments into the GH issue tracker
… So everythinbg is in GH
<renato> https://github.com/w3c/poe/projects/1
renato: That shows you a visualisation of the issues
… Last column means it has been completed and will be closed.
phila: Will be interested to see how this works - I can see this approach being very useful and widely adopted. Thanks renato
renato: The ones that were sent in recently... about half have been completed (the easy ones)
… Editorial and simple ones have been addressed.
renato: If solutions in col 3 are OK then we can go ahead
renato: We decided to look at the ones marked for WG discussion.
<renato> https://github.com/w3c/poe/issues?q=is%3Aissue+is%3Aopen+label%3A%22Needs+WG+Decision%22
renato: Those are the ones earmarked for WG decision
renato: Asking which requirements in the UCR have been met.
… Simon has suggested opening submission of new use cases.
simonstey: I'm fine with reopening this, but if we allow Antoine to add new use cases, wed have to allow everyone.
simonstey: We may decide to re-factor his use cases
<simonstey> https://github.com/w3c/poe/issues/156
<victor> In any case, UC or not, RightsStatements.org provides 12 standardized rights statements. I believe it would be a nice idea to try to model each of the 12 rights statements.
<simonstey> Also not all requirements for use cases have been captured. To start with, the RightsStatements.org case could be used to motivate more requirements. In addition to the current focus, rightsstatements.org can articulate other use cases paired with existing requirements, namely:
<simonstey> POE.R.V.15 - for our statements NoC-CR and NoC-OKLR Perhaps new entries under POE.R.E (Encoding) following our use of relatedURL parameter for statements that need a link to a human-readable legal piece Documenting cases of rights status expiry, which is perhaps relevant to POE.R.DM.06 Would you accept new/revised use cases?
<renato> https://lists.w3.org/Archives/Public/public-poe-comments/2017Apr/0005.html
phila: If Antoine is saying that ODRL doesn't cover Europeana's use cases, then I would urge the WG to take his words on board unless it means a complete rewwrite
renato: So Simon is saying that we should reopen the UC docment?
<simonstey> he asks several times "Would you accept new/revised use cases?"
phila: We can use the evidence of Antoine's e-mail as the basis for adding in features to the spec, without necessarily reopening the UCR
renato: Next one
<renato> https://github.com/w3c/poe/issues/154
Resolved: accept revised use cases from europeana
renato: Current type is a property. Proposal is to make it a subclass, which is how the OWL shows it anyway.
renato: Simon, Vico#r and I are OK with that.
renato: Next - Set is a policy type is a bucket for anything.
… No other semantics
… Question is, do we need it, since it is really a synonym for Policy
… We could say that is we don't say it's an agreement etc then it's just a Policy. We can deprecate Set.
renato: Bit of a change to the current model
simonstey: I initially raised that issue - we treat types of policies more or less the same.
… But we never reference those types of policies
… They're introduced in the vocabulary
… In the ontology, we treat them the same. We have a Policy class and then sub classes
… It continues on as policy types have different semantics
… If you have an agreement, you need an assigner and an assignee.
… Not true for all policy types
simonstey: We use the sub class arrow in the diagram which doesn't match the RDF meaning of sub class
… So I'm all for deprecating Set
victor: I'd like to support Simon
… I believe that we need to keep Set as it is different from a request
… but we can say that by default, a policy is a Set
renato: So rather than deprecate, we just say it's the default
michaelS: I can see in the RightsML spec, that the preferred policy type is Set
… Some contexts don't align with other policy types
… If we want to go beyond the existing policy types., this would be OK with RightsML
<simonstey> :Agreement
… a rdfs:Class , owl:Class ;
… rdfs:isDefinedBy odrl: ;
… rdfs:subClassOf :Policy ;
<simonstey> :Permission
… a rdfs:Class , owl:Class ;
… rdfs:isDefinedBy odrl: ;
… rdfs:subClassOf :Rule ;
michaelS: Flexible ... if a type doesn't exist then Set is the default. I'm happy with that.
smyles: I was going to say that RightsML recommends Set
… If you take away Set as a value and make type not a required property, what is the meaning... what's the default value.
… It sounds like Victor's proposal is that we keep Set but as the default.
phila: Every time we make a statement about cardinality, we need to provide tests.
victor (too quiet)
renato: We're going to have to create tests for everything, yes.
axck s
axk s
simonstey: Your point, Phil, is that those constraints, our test suite has to be able to test for that
simonstey: Suggests that odrl:Policy is the default. Set is just another tyope that doesn't have an further restrictions. That won't break any compatibility with RightsML. But we wouldn't have to provide test cases.
[Discussion about things like type that don't appear in RDF version]
renato: We can do the sub classing, and in the XML encoding, then xml:type is how you assert a sub class of a policy
… It's moving the mapping from 1-1 (XML) to be more class and property based so the XML encoding is what has to be called out separately.
[scribe paraphrase]
simonstey: I think we need to explain the differences between the types in more detail in the model, not just the vocab.
renato: So, things like agreement specified in the model.
simonstey: Yes, we have specs for that. They need to be in the model
… A request has to have two parties etc.
+1 to Simon
simonstey: We don't allow someone to instantiate odrl: Policy. Things like odrl:Agreement only appears as a line in the vocab.
simonstey: I see no reason not to have this in the model. details of each Policy type
phila: +1 to simonstey
simonstey: We don't move them, but we replicate the info. We currently treat Rules and Policies differently. For some reason, policy types are only discussed in the vocab.
renato: I'd like to suggest 2 more WG decisions... I think we can either discuss those at the F2F or do it via GH issues.
<renato> https://github.com/w3c/poe/issues/139
simonstey: I thought we'd agreed that we can remove the undefined actions section and mechanism?
simonstey: I though wed discussed it fully.
… There's this part about undefined actions... how should unsupported actions be processed? I think this is a very specific issue that doesn't need to be defined by us.
renato: I think there is consensus in that direction.
smyles: I agree with removing that section about undefined actions. The Policy should state whether to ignore undefined actions. Are we going to provide advice to implementers?
renato: I guess we should
smyles: Implementers need to know what to do I think [paraphrase]
simonstey: But again, I might ignore every action I don't understand.
… This again relates to what an ODRL processor is?
… That's def a discussion for the F2F
smyles: The concept of a processing engine andwhat that means.
… In HTML it makes sense to say ignore what you don't understand, but that may not apply in ODRL.
renato: The F2F meeting...
<renato> https://www.w3.org/2016/poe/wiki/Meetings:London2017
renato: Logistically, we start at 10:00 on Thursday
phila: +1 to earlier start and finish on Friday
renato: We'll go through the outstanding issues and hope to resolve them and change the docs.
… So by the end of Thursday, hopefully the docs will be updated and all issues resolved.
… Not sure we need to say more than that in the agenda.
… Then day 2 was to look at CR exit criteria
… Then there are the 2 Notes
… We may not finish Thursday until during Friday
… So it's a fluid agenda at the moment
renato: So Simon... for the formal semantic note, is there stuff you want to go through?
simonstey: I think before we even start going through the individual issues, we should discuss what an ODRL processor is.
<simonstey> https://github.com/w3c/poe/issues/161
simonstey: It's relevant for individual issues, the test suite, the semantics etc.
… We need to know clearly what an ODRL processor has to do.
<ivan> +1 to simonstey
phila: +1 to simonstey
<michaelS> +1
simonstey: So I suggest we start by defining an ODRL processor. And then go on to issues.
renato: I've added it to Thursday's agenda.
<victor> https://www.w3.org/2016/poe/wiki/Best_Practices
michaelS: I would call it requirements for a processor
victor: 2 ideas. On the BP Note - Ben and I have had a meeting. I've opened a wiki page to collect examples
victor: And regarding the semantics, we had only 1 meeting so far. The topic was defining what an ODRL Processor was.
… Contradiction between policies etc.
… I think this needs discussion across the group in London
phila: Lots to discuss - should we start at 09:00 Thursday?
[Folks arriving on Wednesday]
renato: So we can start at 09:00 on Thursday
michaelS: Is there a draft for the semantics Note yet?
simonstey: No.
[None]