Market Data Rights Automation Teleconference -- 09 Dec 2020

Admin

<jo_> scribe: joshuacornejo

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

RESOLUTION: Accept minutes of last meeting

Jo: add to the agenda about the in-between meeting from last wednesday

Editors' Update

Mark: do you want me to give a quick update?

Jo: if you would

Mark: it was well attended, showed the demo environment to dynamically generate ODRL
... how it could be retrieved by logging to the human portal
... user can authenticate or via API
... used an old invite list, if anyone interested we can set up another session

Jo: any questions for Mark on that?
... slightly take this out of order, to have first PoC update

Ben: fine by me

POC Update

Jo: Atiq, can you give us a brief

Atiq: working internally on the specific use case. Hand over to Caspar on any new language requirements.

Caspar: one of the things was raised if the text for attribution is internal or external. The right location was within the Policy Store.
... looking at the spec it would be to have extra properties
... with a frequency of update for making it easier for systems to specify different criterias

Ben: are you in a position to pop that on an email ?

Caspar: yes

Ben: thank you. A couple of other areas came out of the discussion of this use case.

<jo_> ACTION: Caspar to forward his comments in an email to the list

Ben: we would expect that the policy store keeps the deontic state of the policy.
... <Ben describes some things are out of scope for this stage>
... then might be things to take on after the end of January and if it is necessary to tackle after the end.

Atiq: yes - we should take baby steps

Ben: anyone has an opinion?

Jo: on Caspar's comments or Ben's ?

Ben: as we are all excited if the PoCs go between organisation to organisation as we are trying to create a supply chain < he goes to describe this in more detail >

Atiq: you read our minds in terms of the full supply chain model

Mark: on our side attribution is not something we expose, but I see no reason why not, sounds like a good idea

Ben: we can take this one step further, <describes use case in more detail>

<jo_> (Ben suggested GS store calling DataBP policy store to get latest version of disclaimer)

Mark: <describes detail on the use case>

Jo: now to Ilya

Ilya: we are now in agreement that this is the right group of targets and we are trying to integrate with DataBP ODRL license generation

<ben> Ben: We might also test out interactions along the supply chain - what is the latest attribution wording; has consent been granted?

Ilya: and to see if we can check to simplify the language
... Ben if I can turn the table around if we are missing something?

Ben: to add, we had a conversation with Ilya's team that the form of ODRL we are using is exactly the same as we are specifying in this working group and is an upgrade of the standard ODRL. And the JP Morgan use case starts testing on a very narrow set of dimensions and once they are working we start testing on more dimensions of the ODRL licenses

Jo: Ilya you said you had no any feedback, good time to do a straw poll to see if there is any feedback and to see if anyone had any intentions to give feedback but had no time
... there being none I guess, Ilya, we can take it that it was perfect in every detail - like Mary Poppins

Ilya: as it was narrow it mirrors what DACS does right now

Ben: do you think we could publish the ODRL you are producing so people can see?

Ilya: maybe for the next meeting

Mark: yes we can see
... you don't have to assume that PoC's are perfect

Comments on the Standard

Jo: a pleasing amount of back and forth on this

Ben: Mark, I wonder if you want to kick off with the meat of the conversation

Mark: I think you would be better

Ben: most of the comments so far are in the supply chain meta model
... very detail and helpful
... one of the things we've done is to expand the party types and to make a distinction between license types
... there is a lot of discussion around a service facilitator and administrator
... to lose the definition, include any third party that is using a consumer's access rights license for any function that they are a 3rd party
... the question of administrator - not resolved yet
... originally thinking of the likes of DataBP
... there are functions within providers and originators that act as administrators
... I don't know if Mark/Nigel/Michelle wants to pick up

Nigel: I think you covered it quite succinctly - if you keep them separate you might end up duplicating and this might just be a different role

Ben: I think I am convinced
... the other area was around activities
... at the more fundamental level, asking if these are events rather than activities
... out there, there is an ontology PROV-O that seems a good target for tracking activities that we might think as an event
... they have start date/end date ... things like reasonable suspicion
... the opportunity into tapping into wider ontologies for provenance

<ben> https://www.w3.org/TR/prov-o/

Nigel: on provenance, PROV-O seems highly relevant to assets, not sure on activities
... need to think about that one about a bit

Ben: it is very good at catching things like analytics or datasets

Nigel: but in my mind, what you are trying to track provenance is in the asset
... not formed a full opinion on this

Jo: further comments on this soliloquy ?

Ben: we should introduce more detail on the elements - this so far covers the majority. Anyone with anything I might have missed?
... I think the standard is getting another layer of detail and granularity
... I suggest everyone read it and focus on any weaknesses, and if we have the right concepts and if we have missed anything.

Mark: I would like to take a few minutes to focus on asset
... <describes his old interpretation and new interpretation>
... I feel a bit uncertain about the resources section of this spec
... we should make 3 distinctions: original data, the resource package and rules to control, and the controlled resource for the consumer
... <describes in detail those 3 distinctions>
... my question is: should we agree/disagree on that state or what should we call it?

Ben: my thinking was that all 3 of these are resources
... 1st and 3rd are kind of special - the source (when we want to point back at this) ... when we want to point back at the source, it gets packaged in some way (real time, L1, German equities, etc)
... the data can be sliced and diced in many ways
... becomes a resource and we point at it and then the permission and becomes and asset
... A resource that has a permission pointed at is a very special type of resource called an asset

Mark: I think we are double meaning the word resource
... we use it for the initial and intermediate stages
... and it is getting a little bit difficult to track through the supply chain

Ben: do you have a suggested name?

Mark: I don't
... and maybe here is where "assets" becomes confusing

Nigel: in this model, would we ever have an intermediate resources outside an originator?

Ben: yes, my point is that the originator might point to an asset and pass it, who could slice and dice and generate new assets ...
... I think any of the roles on the supply chain can do that.
... that slicing and dicing can happen anywhere in the supply chain
... as long as they are complaint with the original license

Nigel: but wouldn't it be covered by rules

Mark: but it can be a different set of rules
... you are allowed to distribute this resource to a 3rd party. But the 3rd party is only allowed to use it internally
... but the asset might be used in different ways

Ben: it is the same asset, just controlled by different permissions

Mark: so when the vendor is in the act to distribute some content. Is that an asset or a resource?

Ben: a vendor gets a real time feed, then they delay it - it has become a different asset. But when they pass it on to their customer, their rules still have to be compliant with the rules for the real time. Which is exactly what we want.

Nigel: you might have these 'naked resources' and at some point they will be converted to assets ... and with the rules that constrain it to an asset.

Ben: Phil, what's your take on this?

Phil: I am supportive of the view that it transforms to a resource when it transfers between parties. One of the things is to identify the resource independent of any refinements. When you are the recipient of something, one of the things that refines the source needs to be stripped away so you can accurately identify that resource.
... yeah I am more supportive it is not viewed as an asset.

Jo: what happens when you combine 2 things together

Phil: that's one of the reasons to try to find the most tangible things, so it makes sense for each part. And that the rules are compliant with all parts of the resource

Nigel: when you are doing the derivation, you need to know where they are coming from so when the rules are applied make sense. It is all about the use cases.
... it is all about the resources and the intermediate representation.

Ben: perhaps for now, all we need is a source and an asset. There are some cases in which might be useful to create further distinction.

AOB

RESOLUTION: There will be no meeting 23rd Dec

RESOLUTION: Service will resume 6th Jan

<jo_> Thanks once again to Josh for scribing

- DRAFT -

Market Data Rights Automation Teleconference

09 Dec 2020

Attendees

Contents

Admin

Editors' Update

POC Update

Comments on the Standard

AOB

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output