<jo_> scribe: joshCornejo
<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: 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
<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
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
<jo__> (hearing none)
<jo_> (many thanks to Josh for scribing)
<jo_> __ meeting closed __
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Topc/Topic/ Succeeded: s/SU/Su/ Succeeded: s/<from phone>/Olga/ Succeeded: s/Olga: the way/Ben: the way/ Succeeded: s/<correct above - it is Ben>// Succeeded: s/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// Succeeded: s/ - /: /g Succeeded: s/SUbject/subject/ Succeeded: s/min utes/minutes/ 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 Found Scribe: joshCornejo Inferring ScribeNick: joshCornejo Agenda: https://w3c.github.io/market-data-odrl-profile/agendas/md-odrl-profile-agenda-2020-09-30.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: ben olga WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]