W3C

Permissions and Obligations Expression Working Group Teleconference

07 Nov 2016

Agenda

See also: IRC log

Attendees

Present
benws2, simonstey, scribe, ivan, sabrina, michaelS, smyles, CarolineB, Brian_Ulicny, victor
Regrets
Chair
Ben
Scribe
phila

Contents


Last week's minutes https://www.w3.org/2016/10/31-poe-minutes.html

benws2: NOTUC?

RESOLUTION: Accept last week's minutes

<simonstey> +q

UCR Note

simonstey: I've started to update the GH version of the doc. I added the remainingn use cases up to no.36, including the BSIG ones
... I looked over our requirements
... Those rejected by the WG, I have made a note accordingly.
... We may want to exclude them or remove them? Or cross them out?
... There are some that we agreed to but they need guidance
... As currently forumlated, they're not reqs.
... POE RR08, guidance on provenance policies, for example

<simonstey> http://w3c.github.io/poe/ucr/#POE.R.R.08

simonstey: IMO, this isn't a req for ODRL, but is a req for the WG deliverables
... So do we keep them there?

benws2: It seems that we have 2 Qs
... Should we keep in the UCR, UCs that we're not going to address, and 2. Do we keep in there reqs that we'll address in documentation

simonstey: There are some Reqs that re not formulated as reqs for ODRL

benws2: My working assumption was that we had previously agreed that we'd keep those UCs on the wiki but remove them from the actual doc.

asck r

renato: From memory... we did state that UCs that we were not going to address still would appear in the UCR but be flagged as being for a future version
... Only reqs that we'll address will be in there, but all UCs are in there.

<simonstey> "Specific requirements that have been de-prioritized or rejected have been left in the document for completeness, but are shown as struck out."

ivan: It's OK if we have reqs that we end up not covering, but some sort of doc should exist that says why we won't/didn't address it.
... There can be any (genuine) reasons.

benws2: But would you include the UCs?

ivan: If they're genuine UCs then, yes.
... Maybe in 2 years' time we come back and look at it again.

benws2: What about UCs that raise Reqs that are already covered?
... If there's a UC on the wiki that we judge to be covered in ODRL
... We agreed only to generate Reqs for changes

<simonstey> +q

benws2: ASking in general, am I right not to include UCs that don't generate any new requirements?

<michaelS> I recall the same

simonstey: I'd say there's value in having a UC that repeats another one's reqs
... The UCs tell you what people want to use ODRL for.
... We don't want to add something to ODRL that isn't required by anyone

phila: IMO the UCR should refer explicitly to the original ODRL UCs and say thaty we're building on top of that.

michaelS: I think the reqs doc shouldn't include what's alreadty covered, but the wiki can.

benws2: In the UCR, should we have UCs that generate no Reqs because they're already covered??
... Were OK with UCs that generate Reqs we're not going to cover

renato: For example, UC31 on internal rights management

<renato> trackbot, status

renato: We decided last week that it was all implementation specific. So do we remove 31?

benws2: I think there are 3 classes of UC
... 1 asking for exsting ODRL functgionality
... 2 asking for guidance that we can link to the BP doc, eg using Prov
... 3 UCs that do generate new Reqs but that we're not going to cover

renato: So 31 is an implementation issue.

benws2: If it wont even make the BP doc then I'm not sure that we shoijuld include it - we have nothing to say about it
... For the vote...

<simonstey> no

benws2: Those UCs that generate no new Reqs, should they be in our UCR document?

<simonstey> +q

phila: Emphasises desire for link to old UCs

simonstey: My no relates to UCs like the one Renato mentioned which was about implementation issues. I don't think that should be part of the UCR.
... Reqs that were gathered years ago, they need to be part of the UC document, at least by reference.

benws2: That can be in a para t the top. These UCs extend the existing set that drove dev of ODRL

PROPOSED: That we don't include use cases in the UCR Doc that generate no requirements and no guidance.

<simonstey> +1

PROPOSED: That we don't include use cases in the UCR Doc that generate no new requirements and no guidance.

<ivan> +1

<Sabrina> +1

<CarolineB> +1

<Brian_Ulicny> +1

<michaelS> +1

<benws2> +1

<simonstey> -0.9

<renato> 0.5

<smyles> 0

RESOLUTION: That we don't include use cases in the UCR Doc that generate no new requirements and no guidance.

<simonstey> old reqs https://www.w3.org/2012/09/odrl/archive/odrl.net/2.0/v2req.html

benws2: Are the editors confident enough to make progress towards a version for publication in December?

simonstey: This Q about reqs, those we've rejected, do we keep them in the doc?

michaelS: My thinking is that if we don't include the UCs in the UCR, what about using them for a BP doc?
... I think some are interesting and attractive for marketing

<simonstey> requirements != use cases

benws2: I agree. Any UC that generates that kind of thing is good.

renato: Are we going to close off the UCs?

benws2: We could, but I don't feel under pressure to do so.
... Can we change it after we've published?

ivan: You can publish new versions as often as you like. It's a Note

benws2: So there's no pressure (literally not a euphemism)

simonstey: You can change FPWDs at any time and they can be different.

benws2: if were sinking under the pressure of new UCs OK, we could close the list, but we're not.

renato: The BSIG has got back to us with clarification, We can discuss that next week.

The Model

renato: On Complex Constraints... it's 3 weeks since we spoke about that.
... The minutes said we've move the discussion to e-mail. Has there been any new thoughts?

<simonstey> +q

benws2: The one that seems most obvious to me is the chaining of constraints but Simon said that's a processing problem.
... Can we design those problems out?

Sabrina: I sent a mail to the list just before the call. I checked with colleagues about how to describe these using DL. I was told it's outside the scope of OWL 2, as they're linear constraints.
... But pointed to a W3C Note on OWL2 and Linear Constraints
... The semantics and decidability is clear and published. There are existing reasoning engines that will handle it. But it's outside OWL2.

Brian_Ulicny: What is a linear constraint?

Sabrina: Some sort of dependency between two things Think of a less than statement, need to evaluate both.

ivan: That Note has never had any continuation.
... I wouldn't go down that line... trying to put it into the OWL 2 framework. We don't have the expertise

simonstey: Maybe I want to talk about this at the F2F as I'd need more time to ramble about it. Main question... the role of constraints in ODRL.
... Do we want them automatically evaluated? Or is it just about making them machine readable?
... It could just be a variation on plain text.
... I could talk about this for hours.
... We need to be clear. We could potentially chain constraints for ever.

<renato> https://www.w3.org/2016/poe/wiki/Requirements#POE.R.DM.02_Define_target_of_a_constraint

renato: In an ideal world it would e great if we could design and build such a system but that's more than we can do. I think it's expression and machine readability that we're aiming for.
... We have another req....
... We can augment the constraint model so that you can specify the target of the constraint.
... We can say that the target of the constraint is another constraint.

smyles: In order for us to help people implement machine readable rights, we do need to document the processing model.
... We tried to do this in RightsML
... If we don't document the processing model, then we're just codifying natural language. We could stop there, but it would be useful to go further

<ivan> +1 to Phil

<renato> +10000

phila: You can have a processing model but that entails independent software to implement it, test suite etc.

renato: We can have a model where a constraint has another constraint. That's easy in the model.
... We could do that soon and then the WG can see what the outcome is.

Extended Relations

renato: qI wasn't clear on the state of req DM10. Are we waiting for more explicit use cases?

benws2: For XOR, I can generate loads of use cases.

renato: Can you send some in

benws2: Yes

<scribe> ACTION: benws2 to submit use cases about extended relations [recorded in http://www.w3.org/2016/11/07-poe-minutes.html#action01]

<trackbot> Error finding 'benws2'. You can review and register nicknames at <https://www.w3.org/2016/poe/track/users>.

<scribe> ACTION: benws to submit use cases about extended relations [recorded in http://www.w3.org/2016/11/07-poe-minutes.html#action02]

<trackbot> Created ACTION-36 - Submit use cases about extended relations [on Benedict Whittam Smith - due 2016-11-14].

Vocabulary

renato: Simon raised the issue about removing terms that came from a long time ago.
... They may not make a lot of sense today.
... We had a discussion at TPAC about normative and non-normative terms
... Normative means implementations

<simonstey> victor raised that issue a year ago too -> https://lists.w3.org/Archives/Public/public-odrl/2015Apr/0024.html

renato: The question we face is... do we solve those together
... We can say we think these terms are normative, non-normative, at risk etc.

michaelS: What makes a term normative? What is the distinction.

<simonstey> +q

renato: If you have a section in a spec that is normative, you need multiple implementaions

simonstey: I put a link in - Victor raised this a long time ago.
... The core issue of this issue is why certain terms are in ODRL.

<renato> "I love ODRL and the ODRL core model" - thanks Victor ;-)

simonstey: Why can't we have all those terms? Because there are too many.
... We can have the general concept of an Action, in the core, and then people can extend with what they want like 'accept tracking' etc.
... Not best to have them in the core

benws2: We have to go through a process of splitting terms into normative and non-normative
... What were you suggesting as a process?

renato: Other people need to look at the terms rather than me as I'm too martied to it.
... Especially the names for constraints.
... Check them off as at risk terms, like 'inStore' might be too outdated

<simonstey> +1 to phila's proposal

<simonstey> +1

<simonstey> +q

phila: Enumerations = obsolescence

<smyles> obsolescence

simonstey: That's my point (what Phil said)
... As actions are used in ODRL, even if there are 20 ways to say print, there is no problem with having new ones. You don't gain by having them normative.

renato: Why don't we say that all the terms from the info model are normative and the rest, not normative?

simonstey: Some terms are there nbevcause some time ago the right person asked the right person.
... Talks about managing narrower and broader terms

<Zakim> phila, you wanted to talk about the CG

michaelS: From IPTC experience, interop is a problem if you open up fully.

benws2: But isn't that the role of the news industry to provide the terms.

<simonstey> +1

<simonstey> +q

michaelS: Sure we can do that for RightsML, but if a news term should be used for a text book? They have different action defn.

ivan: The annotation WG had a similar issue for what we called Motiviations

<ivan> http://w3c.github.io/web-annotation/vocab/wd/#extending-motivations

ivan: We added into the doc, a non-normative guideline on extending. You should do it this way etc.
... We defined some of the top level ones and then how to add your own.

simonstey: That's what I imagined too.
... To respond to Michael - things not being in line, if we have the concept of a profile, you can't stop people defining their own profile.
... People will do what they will do.

F2F

renato: We have got 2 options: Madrid (Victor has offered)
... And offer 2 is New York
... Monegraph would be happy to host that.
... So the question now is what's the decision.
... For March

<Sabrina> not necessarily.... NY is great

<scribe> ACTION: phila to set up WBS to help decide F2F venue [recorded in http://www.w3.org/2016/11/07-poe-minutes.html#action03]

<trackbot> Created ACTION-37 - Set up wbs to help decide f2f venue [on Phil Archer - due 2016-11-14].

<victor> (oh! I am afraid I arrived in the last minute...)

Summary of Action Items

[NEW] ACTION: benws to submit use cases about extended relations [recorded in http://www.w3.org/2016/11/07-poe-minutes.html#action02]
[NEW] ACTION: benws2 to submit use cases about extended relations [recorded in http://www.w3.org/2016/11/07-poe-minutes.html#action01]
[NEW] ACTION: phila to set up WBS to help decide F2F venue [recorded in http://www.w3.org/2016/11/07-poe-minutes.html#action03]
 

Summary of Resolutions

  1. Accept last week's minutes
  2. That we don't include use cases in the UCR Doc that generate no new requirements and no guidance.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/11/07 13:41:02 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/I'd say there's no point in having a UC that repeats another one's reqs/I'd say there's value in having a UC that repeats another one's reqs/
Succeeded: s/buyt thaty/but that/
Succeeded: s/cvses/cases/
Succeeded: s/obscelence/obsolescence/
Found Scribe: phila
Inferring ScribeNick: phila
Found ScribeNick: ph
WARNING: No scribe lines found matching ScribeNick pattern: <ph> ...
Found ScribeNick: phila
ScribeNicks: phila, ph
Present: benws2 simonstey scribe ivan sabrina michaelS smyles CarolineB Brian_Ulicny victor
Agenda: https://www.w3.org/2016/poe/wiki/Meetings:Telecon20161107
Found Date: 07 Nov 2016
Guessing minutes URL: http://www.w3.org/2016/11/07-poe-minutes.html
People with action items: benws benws2 phila

[End of scribe.perl diagnostic output]