Minutes of the W3C Rights Automation Community Group 2020-09-30

Please find the minutes of today’s meeting at https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html and pasted below.

Summary of Action Items

ACTION: Ben to provide worked example of netting
ACTION: Olga to write up the example of tri-partite agreement that she has illustrated


Summary of Resolutions


  1.  Accepting minutes of last meeting<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#resolution01>
  2.  Accept the proposal of the breakout group to use the terms subject and Object in place of Debtor and Creditor<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#resolution02>

Many thanks
Jo

Market Data Rights Automation Teleconference
30 Sep 2020

Agenda<https://w3c.github.io/market-data-odrl-profile/agendas/md-odrl-profile-agenda-2020-09-30.html>

Attendees
Present
jo, ben, josh, Laura, caspar, ilya, michelle, sam_Reiss, markb, Olga
Regrets
renato, adamh, paulk, markD, Stephen_D, Adam_D, Phil_R, Tom_D, Michael_J
Chair
jo
Scribe
joshCornejo
Contents

  *   Topics<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#agenda>
     *   Admin<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#item01>
     *   Ben on Netting<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#item02>
     *   Creditor / Debtor<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#item03>
     *   Definition of Compliance<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#item04>
     *   AOB<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#item05>
  *   Summary of Action Items<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#ActionSummary>
  *   Summary of Resolutions<https://www.w3.org/2020/09/30-md-odrl-profile-minutes.html#ResolutionSummary>

________________________________

<jo_> scribe: joshCornejo

Admin

<jo_> https://www.w3.org/2020/09/16-md-odrl-profile-minutes.html


Laura: from actions from last week, she has the materials together and will forward later

Jo: for the events from 2020, one that ties into market data, haven't seen anything on that: leaving it open for next meeting

Ben: not yet progressing on PoC

Jo: close that action around PoC
... not done anything on the action assigned to himself

RESOLUTION: Accepting minutes of last meeting

Ben on Netting

Ben: I understood the use case that Ilya wrote, this happens around display permissions?

Ilya: yes
... unless Olga or Michelle tell me I am wrong

Ben: kindly linked to licencing, I guess the work of netting it should say "if I have a user that has multiple devices, from multiple locations, we are not going to charge you independently, we are going to net-it"

Ilya: we should narrow the devices to one

Ben: the differences between those two is how netting is effected. NYSE by generating a set of credits, effectively pay "un netted" and calculate a discount. CME seems happy that you pay the netted amount. Is that a fair summary?
... it seems to me the way to approach the modelling of this is to have an obligation to pay, in the case of NYSE both by device and provider. Now several different permissions from different vendors might point to that obligation. That payment will made on that obligation. Then there is a duty on that obligation on credit the net discount on the following invoice. That: I think: captures what is going on in here. As an add[CUT]
... discount duty to report that netted file and also to consent to an audit of that netting.

Ilya: the difference between those two sets in NYSE is optional and depends on the consumer providing reporting. It is essentially a dataset specific option. There is a potential need to reference ...

Ben: I take the point but it seems to me ... if Refinitiv and Bloomberg provide NETA or NETB ...
... then those permissions coming from Vendors are aware that this is net-able. And they all point to the same payment obligation.

Ilya: mechanically there will be separate licences. Essentially there will be nothing in the licence.

Ben: those permissions over accessingNYSE will be aware that they are net-able.
... and point to the same payment obligation.

Ilya: if you have a licence from NYSE and covers multiple datasets and only one of them is netable. In that case you will have to point it to the obligation. In case of the DBoerse, you have a site license that covers multiple datasets

Ben: that seems quite different from the other two.
... is it true that you can have access to L2 info but not L1.

Ilya: yes, there are ...

Ben: can you get the L2 info and not get the L1 and data makes sense?

Ilya: there are some examples, like spoofing detection, you derive L1 from L2.

Ben: the approach of that use case is specific, we can specify any combination into the definition of the resource

Ilya: if there is a way to address a resource, it might be difficult to have a licence that shows a different resources.

<benws_> ACTION: Ben to provide worked example of netting

Mark: apologies for joining late

Ben: you missed a scintillating conversation about netting

Mark: this is my favourite type of conversation

Creditor / Debtor

<jo_> https://lists.w3.org/Archives/Public/public-md-odrl-profile/2020Sep/0006.html


Mark: the purpose was very simple, to find 2 new words to replace Creditor/Debtor that we use in the context of an action. Creditor is the person to whom the action is being done, the Debtor is the party responsible to do it. It was concluded that it was fundamentally a gramatical problem.
... that it was a subject / object /action.
... the first part is to call them subject and object

<jo__> PROPOSED RESOLUTION: Accept the proposal of the breakout group to use the terms Subject and Object in place of Debtor and Creditor

RESOLUTION: Accept the proposal of the breakout group to use the terms subject and Object in place of Debtor and Creditor

<jo__> https://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#Duty%20Functions


Mark: one of the problems with using very generic terms is that generalisation. The breakout group all agreed that conceptually for a particular action, we can name the subject & object more specifically.
... as humans interpreting that action we can specify more when we know the specific action
... the advantage is that maintaining more define the consuming system can know what is the context of specific actions, but make the ODRL more complicated to maintain.

Ilya: that is a very good summary, important to highlight that Subject/Object are not necessarily always implicit. In some cases they have to be called explicitly.
... do we have multilateral contracts?

Michelle: we can have triparty agreement

Mark: in that case: the market example: one licensing entity, multiple sub-entities would use it. In both cases, in a particular contract, the subject and the object must be resolved to a specific entity

Jo: there was another point, which was in a different case where sub/obj switch over. How do we fill in the appropriate way.
... is that correct? am I right it is a concern? and the example clarifies the confusion.

Ben: sometimes the concern is that there is more than one party

Jo: I don't think that was the point before

Mark: if you have mutability depending of the context, making it explicitly define so an automated parser doesn't get confused.

Olga: how are rights inherited, and passed over

Ben: explains via an example

Olga: DBoerse, they request data from Refinitiv ...

Ben: the way we handle that the permission to handle XtraUltra, we get permission from BBoerse, we have a policy where there is an understanding that Refinitiv is the assigner and Morgan Stanley is the assignee, and the policy has further details for M.Stanley and D.Boerse

Olga: explains further

Ben: Olga if you can give us an example, we will work through the example

<jo__> ACTION: Olga to write up the example of tri-partite agreement that she has illustrated

Olga: OK

Ben: if you could work it out

Definition of Compliance

Ben: in the end, what we are trying to do is to show compliance and we are using the data compliantly, to be absolutely clear on which rights and obligations. This group has been focused on making this clear. But that is not all of compliance, there is another part that checks if this policy compliant with the originator's policy?
... this are actually questions of logic and the definition of compliance can be specified
... or should we just describe it textually ?
... we want the entire supply chain to agree on this
... is there something we can say in the standard to guide the supply chain?
... Casper what are your thoughts?

Casper: it would be good to explore what can be built on top of these, we don't want to slow down the main thread. I am not really sure on what to say.

Mark: I think we are aiming for a specification that can make binary yes/no decisions. I agree that is the goal, I acknowledged there are grey areas and pointing them out there is a definition of compliance. And down the supply chain that can be agreed, and the grey areas can be shown to all parties.

<jo__> PROPOSED RESOLUTION: Definition of compliance is left as a matter of human judgment making sure that we make sure that the "grey areas" question is noted

Ben: to some extent this is an exercise in expectation management, we should be clear about these grey areas. But what was at the front of my mind, we are in a transparent space. Should we put some effort into what is out formal definition of compliance?
... if you agree with our definition of compliance ...

Olga: we cannot push it aside completely

Ben: yep

Jo: Ben to put this on the agenda for subsequent meeting
... we will continue this topic in a subsequent meeting

AOB

<jo__> (hearing none)

<jo_> (many thanks to Josh for scribing)

<jo_> __ meeting closed __




---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.