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)