Minutes of the W3C Rights Automation Community Group 2021-07-21

Please find the minutes of today’s meeting here <https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html> and pasted below.

Summary of action items

  1.  ben to write this up testing approach scenario he described<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#a01>
  2.  ben to document the examples he stepped us through on this call<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#a02>
  3.  ben to call a discussion on this idea re versioned terms<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#a03>

Summary of resolutions

  1.  Accept minutes of last meeting<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#r01>
  2.  put the question of relationship with CDMC and FINOS into the parking lot for now<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#r02>

Market Data Rights Automation Teleconference
21 July 2021
[IRC log.]<https://www.w3.org/2021/07/21-md-odrl-profile-irc>
Attendees
Present
adam, ben, caspar, flora_golshan, markb, michelle, nigel
Regrets
laura, renato, tricia
Chair
jo
Scribe
jo
Contents

  1.  Admin<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#t01>
  2.  Testing approach<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#t02>
  3.  Derived Products<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#t03>
  4.  Update on standard<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#t04>
  5.  AOB<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#t05>
  6.  Summary of action items<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#ActionSummary>
  7.  Summary of resolutions<https://www.w3.org/2021/07/21-md-odrl-profile-minutes.html#ResolutionSummary>

Meeting minutes
Admin

jo: meeting on FESE terms, outstanding
… ben to draft versioning text

ben: started that, but had another thought

jo: caspar to look at deprecation policy of ISO terms

caspar: started but on holiday

jo: ben to put prefixes in

ben: they are going in will show

jo: caspar to verify that M49 codes can be represented with a URN
… will come back to next meeting

Resolution: Accept minutes of last meeting

Testing approach

ben: primarily relates to implementations, publicly as much as possible so we can get interoperability data
… aware of pieces of work starting or in train
… would like people to write this up as part of the community group
… we are looking at enforcement through cloud data exchanges
… will refer to adam later

adam: what does this look like to you?

ben: provider is aware of permissions customers already have, so they don't need to re-paper all over again

adam: ADX is a lot of historical, so the policies are not all that robust
… also would be good for someone to pull real-time data

ben: small step by small step, in scope, not straight away
… so it's important that we can reference and write them up and so publish the interoperability tests through community group

markb: how much does this differ from the approval poc we did with Caspar
… is this a request that the exchange is making to the originator?

ben: complimentary to what we did before
… another tests is can a provider have their customer permissions
… atthe other end there is a third poc - fine grained permissions - hit data base and get a yes or no

jo: useful to write this up

Action: ben to write this up testing approach scenario he described

Derived Products

mark: wanted to examine this, possibly a good practical case
… was thinking about "transformed through some trasnformation ..."
… becomes a new asset only if is irreversable and so on
… does this mean it skips the source stage
… original creators may have rights that persist into this derived asset

ben: welcome this topic being raised
… we need to get derivations right ... indices ... and want to share with customers
… looked at re-writing that para ...

(shares current version)

ben: news text adds includes saying that it creates a new Source
… which can then be packaged in many ways for different customers

mark: so how to the original constraints and obligations flow through?

ben: are we comfortable with creating a new source

caspar: need to think about the "non-substitutive"

ben: would be the same asset then

(general agreement)

ben: you never get the one without the other,
… in fact there is a third "reverse engineer" but that's entailed in irreversible

flora: different sources treat raw data differently
… fixed income you are putting data though your own methodology, combined with others etc.
… then it's yours.
… if you are going to argue that the resulting data is yours then that's arguable, and different arguable as to
… whether its monetisable or non-monetisable

ben: IP owner can be specified can be different for derived data
… they still want to be able to control what you do with it, even if it's your own IP

(ben shows example)

ben: translation of the Deutsche Boerse non display
… allows you to generate indices but then controls what you can do
… and says they can only be used for benchmarking purposes
… any new output has to be controlled by V1 ...

(continues to look at the example)

nigel: possible problem, if you say you are creaating a source when you derive data
… but a source is not encumbered by a policy

ben: it's really just an abstraction that allows you to create Assets - and they are all controlled

michelle: found one the other day - concept of 2nd generation product

ben: interesting, think that this is an implementation fo that idea
… would be good to get the reference

adam: how does this execute
… someone takes the data ... makes a derivation ... how is the system supposed to know
… that there is a new license to apply

ben: good question, we'd only really know once we try

(gives example, relating to data lineage)

(adam expresses concern as to whether this can be automated)

(ben says it's all about a subsumption check)

Mark: this is all about two parties, how does it work with a third party

ben: yes, it is a valid use case ...

(gives example)

ben: you only need to check the policy of your supplier, since this has to be compliant with their supplier, down the value chain

ben: CDMC and maybe FINOS for APIs will be an important next step

(discussion about applicability with CDMC)

adam: discussed the need to reference policies, for example, calling policy store API
… concerned about the various layers of consortium activities

ben: work has started in defining some of those APIs
… need to make them public, and we're generating more of the APIs

Action: ben to document the examples he stepped us through on this call

Resolution: put the question of relationship with CDMC and FINOS into the parking lot for now

Update on standard

ben: putting namespaces into standard
… also adding references
… also regulations
… and versioning, started writing referencing Caspar's and Nigel's work on standards
… but how do you manage a living document against needing to reference standard versions
… climate scientists have a similar problem
… never change a definition of a term, always the same, but can be deprecated
… they version the term
… suggest that we never allow a breaking change to occur
… if a processor comes across a version of a term more modern then it can fail gracefully

(discusses prohibitions)

ben: so we can minimise impact of new terms, and may have greater flexibility

Action: ben to call a discussion on this idea re versioned terms

AOB

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