Re: Minutes of the W3C Rights Automation Community Group 2021-02-17

I’m so sorry for the near-duplicate email everyone, cut-n-paste in haste, repent at leisure, as they always say.

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

Summary of action items

  1.  Ben to clarify fungibility<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#a01>
  2.  Michelle to find examples of disaster recovery<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#a02>
  3.  Ben to chase re chat on Zoom<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#a03>
Summary of resolutions

  1.  Accept minutes of last meeting<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#r01>

 Rights Automation Community Group Teleconference
17 February 2021
[Agenda.]<https://w3c.github.io/market-data-odrl-profile/agendas/md-odrl-profile-agenda-2021-02-17.html> [IRC log.] <https://www.w3.org/2021/02/17-md-odrl-profile-irc>
Attendees
Present
adam, ali, atiq, belen, ben, caspar, ilya, jo, josh, laura, mark, marko, mevan, michelle, nigelp
Regrets
renato
Chair
Jo
Scribe
jo, joshuacornejo, nigelp
Contents

  1.  Admin<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t01>
  2.  Progress against completion<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t02>
  3.  solving for the Test Cases<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t03>
  4.  commingle<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t04>
  5.  Store Action<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t05>
  6.  Business Continuity<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t06>
  7.  Location, geography, and line-of-business constraints on users<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t07>
  8.  PoC Update<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t08>
  9.  AOB<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#t09>
  10. Summary of action items<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#ActionSummary>
  11. Summary of resolutions<https://www.w3.org/2021/02/17-md-odrl-profile-minutes.html#ResolutionSummary>

Meeting minutes
Admin

Minutes: https://www.w3.org/2021/02/03-md-odrl-profile-minutes.html

Resolution: Accept minutes of last meeting

Progress against completion

ben: three criteria for completion, 2 pocs. We had the first one, second one will hopefully be demonstrated next week
… second criterion was test cases, we'll be discussing that today
… third is to be able to translate the same licenses supplied by laura
… so good progress to finish at end of march

<joshuaCornejo> Sorry - meeting overran

ben: finish mean publish first draft
… then two quarters of implementation reports and feedback etc.

jo_: Need two conformant implementations to declare victory.
… hope to have standard out end Q1 but continue to take feedback through next couple of quarters.
… need process for maintenance / bug-fixes to standard

solving for the Test Cases

ben: 67 test cases defined.
… reviewed test cases and identified a few potential missing elements.
… (discusses issues raised in github)

commingle

Nigelp: captured in the comment agaist the commingle issue - arises in contracts around use of data - e.g. Nasdaq single stock rule
… refers to derived data, also in the case of index licensing, where small amount is OK but more would require additional terms
… i.e. limitations in use so a constraint

laura: don't have to deal with commingle
… we'll get the question can I commingle? And it ends up being a question of derivation

michelle: the licenses don't deal with the term in this way so is a constraint

ben: recall that commingle constraints on a data set from my refinitiv days

Store Action

ben: moving to "store" Action

NigelP: storing is an action, you get contract clauses around where you can store the data, if it is in-country, you need to adjust the storage location
… questions around what happens at the end of the contract, rights to store the data
… or any rights to keep, a minimal subset of it for regulatory purposes
… constraints by location

Adam: what do you expect to happen, you don't expect a machine to auto delete

Nigel: the standard is a digital representation of the ideas of a contract ... someone might be ambitious to implement a system

Ilya: you need a machine to know what the rules are

Ben: Adam, the answer to your question, the level of this standard is to specify what is there and the implementation is on a per case basis

Atiq: do we expect a catalogue?

Nigel: is location effectively standardised or client specific?

Ben: if we can delay to after the next issue, that would be good

Mark: Nigel, you mentioned use cases? Is there a need to define specific use cases?

Ben: Nigel has already identify a new purpose, which is for "regulatory purposes". If there are any more purposes, we should be adding them

Nigel: not at the moment - we will continue thinking

Michelle: usage for backtesting/analytical for historical purposes it might be a requirement
… it would be good to make sure we capture it

Ben: <speaks about the GitHub #27>

Nigel: the example I am thinking here - there is a major data vendor, they have a policy related to historical data, they will license it in 2 explicit terms: historical data, the right to store and use it for historical purposes, but there is also a narrow carve out: you can store data, provided you only give it to people if they are paying for one of our desktop products

Mark: are those third party?

Nigel: that would be internal

Ben: my question remains

Nigel: in that case, if you take the delay product, they don't consider you are storing the data - it wouldn't be considered an example

Ben: I can hold to my belief that data is fundamental fungible.
… does anyone have an example where it is not?

Jo: it would be good to define 'fungible' ? A piece of data is just a piece of data, irrespective of the path

Ben: ... and it would be controlled by multiple licenses

Nigel: you are more likely to see issues with this fungibility because it is possible there will be additional licensing restrictions that would be present in the provider vs contracting to the exchange directly
… for example LME allows you to take data from their trading platform and give it to your clients for trading purposes. But if you use identical data from a different vendor, you will require different licenses.

Ben: but you would have different licenses, and I would always try to use the most permissible one to access the data

Michelle: it is most likely the license that will tell you
… most of Refinitiv licenses will tell you that you need an Exchange license

Jo: personally I like the word fungible, but for clarity - this work is not encumbered by any data provenance considerations

Ben: we have to be careful on how we write this sentence

Action: Ben to clarify fungibility

Business Continuity

Ben: if there is a permission that has the purpose of business continuity, does it give me permission to do testing or is it to cover the case of an asteroid hit and now I need this permission to run the application in this new environment

Nigel: the distinction makes sense, the examples we can see tend to look more like the limited rights to use the data in a temporary basis without having to do additional reporting

Ben: and to continue doing your business

Ben: Laura, do you need these DR clauses ?

<Laura wasn't online>

Jo: if it is a purpose, is using the data for your DR testing a purpose?

Action: Michelle to find examples of disaster recovery

Nigel: if you've got the right, it will assume that it includes an element of testing

Jo: do you use it?

Nigel: yes, but we tend to use multiple production sites, splitting the application
… because that is a much better way to know it is going to run on the day

Caspar: in the event of a disaster, would your reporting obligations kick in?
… would it be a distinction there?

Nigel: it will all depend on the license
… we wouldn't typically use this scenario for major market data - in a primary/backup with both production users
… not ruling out we use it but not for our majority of use cases

Location, geography, and line-of-business constraints on users

Ben: most of the questions are constraints on permissions - location, geography, line-of-business
… And it comes to your question Atiq - in terms of geography we can use the standard UN regions/subregions.
… But locations, we cannot standardise. Will always be specific to the assignee.
… The assignee will create their own list of locations coming from their contracts and agreements.
… then there is line-of-business that sits between the two
… some times these permissions will be tied to specific desks
… like location
… Atiq: what is your feeling about this?

Nigel: there is a pattern that we might be able to apply in this case, it is usually in a schedule tying a set of applications to those things explicitly

Adam: how do you do it without assuming, for some sort of automated reporting

Ben: I agree with you adam

Nigel: we should make the distinction between what we want to get into the standard and fully automation end-to-end

Ilya: there will be some standardisation and some outlier schedules with some text field - there is no standard way to chop business into standard cases

Ben: we can give some guidance to recommend how to automate some of this

Atiq: as more firms reach into the cloud, there will be commonality across businesses

Ben: in terms of LoB - is there anything else people might want to add to that list?

<jo_> (the list being: front, middle, back, buy-side, sell-side)

Caspar: do you want give us an update on the PoC for the 3rd of March?

PoC Update

Caspar: <describes the progress>

Ben: any questions on that ?

AOB

Action: Ben to chase re chat on Zoom

jo: hearing no other business
… meeting closed (with thanks to Nigel and Josh for scribing)




---
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.



---
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.