- From: Rimell, Phil <phil.rimell@refinitiv.com>
- Date: Wed, 22 Jul 2020 16:14:20 +0000
- To: "public-md-odrl-profile@w3.org" <public-md-odrl-profile@w3.org>
- Message-ID: <4CD21F95-AD72-436E-8880-F7201FE44D47@refinitiv.com>
Please find the minutes of today’s meeting at https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html and pasted below. Summary of Resolutions 1. Last meeting minutes accepted<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#resolution01> 2. accepted terms in vote doc except report and notify<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#resolution02> Best regards, Phil Rights Automation Community Group 22 Jul 2020 Attendees Present Ben, Phil, Mark, Natasa, Josh, C, Ilya, Paul, K, Stephen, D, Olga_M, Aaron_G, Casper_M, Fred_S, Jeremy_B Regrets Renato, Mark_D, Elizabeth Chair Ben Scribe Phil Contents * Topics<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#agenda> * Admin<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#item01> * Editors’ Update<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#item02> * Any Other Business<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#item03> * Summary of Action Items<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#ActionSummary> * Summary of Resolutions<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#ResolutionSummary> ________________________________ <scribe> scribe: Phil <Ilya> + <Ilya> regrests+ Michelle Roberts Admin <benws> https://www.w3.org/2020/07/08-md-odrl-profile-minutes.html RESOLUTION: Last meeting minutes accepted <benws> https://w3c.github.io/market-data-odrl-profile/discussions/2020-07-22/terms.html Editors’ Update Discussion of Duties Mark: to speak through document on duties ... invites feedback ... will take topics and balance technical info with examples and links to other threads ... goal is to proceed down document, gain understanding and take a vote ... we'll start with talking about the request duty ... picking out the main points key to the request is that the debtor is the part that has to make the request Mark: example is approval for bring a facilitator onboard Ben: let's discus action by action Ilya: a question about request vs compensate Mark: I'd like to generalise ... another example would be a data vendor needs permission to deliver data to another firm ... should we build out the actions scope a little more? Ben: yes ... action scope should be distribution ... ilya, in your please clarify your example ... an issue is also open about types of policies ... a request at a policy level is different to a request at a duty level ... we need to hash this out Ilya: concerned we could spend alot of time on a duty discussion Ben: if we can agree on these common use cases that is progress, we dont have to cover all use cases ... timebox discussion for 30 mins at most Ilya: requirement to count snap for non pro users Mark: that is possibly duty to report ... report is different from notify in that ii is periodic Ilya: would suffice if rich enough Ben: we can already count snaps, will come to later Mark: lets get our arms around big aspects of these duties ... key to our industry is approval to distribute, involve service facilitator etc ... there is a different between audit required by exchange vs request by a part to use a service facilitator ... there need to be consent in one (the faciltator) not in the other (the audit) Ben: in both cases we're trying to capture that permissions get invalidated if consent not given ... can withdraw request to regain permsiion Mark: sounds right. the debtor is the party that has do do the thing Jo: a question re creditor and debtor as they dont resonate strongly. can we change them to improve indertsandability ? ... can we open an issue on this? Ben: alternative have been offered, let's ask the attendees now.. <Ilya> +1 <OlgaM> +1 Ben: that's a convincing vote, we need to change terms! Mark: i'll revise doc to reflect new terms when avaialble ... we've talked about request and consent, lets no do notify ... could also be in report thread ... duty to notfy e.g. i've begun using your data product ... use case where an originator doesnt need an order but does need to be notified Ben: i used the DB example where they need notification of use of their data ... if a vendor turns on a client is that the same notify? I think yes Mark: any other contractual notification duties? Ben: service facilitator - notifying the excahnge? <jo> regret have to drop off Stephen: approval processes common, sometimes just notification Ben: ok, so most of those are in the request and consent pattern, some in notify ... time element can be managed through time intervals and deadline deltas ... one a request come in a timer starts ... a deadline delta is a window to execute the duty ... time intervals between audits can be modelled too Olga: yes, i think that answers my questions on timing, consumers and vendors are subject to timing constraints Mark: re ownership events and notifications, and contact changes and notificatuions Ben: we have to decide on scope, what's important enough? We are focussed on rights assignments and their validity. Ilya: scope might grow over time Mark: let's look at duty to report ... mainly/always upstream reporting? Ben: in my experience yes Mark: difference between report and notification? Ben: it is true that reports are repetitive but the differece bewteen report and notify is in the structured nature of reports ... the report has a form, the notification does not Ilya: i dont fully agree, i suggest report is a timed activity on a schedule whereas a notification happens on an event Ben: make sense and natural Aaron: notify is asking for permission, reporting is more hsitorical Ben: yes Olga: sometimes notification can include a report Ben: yes, i take these point and i will amend definitions ... key distinction between these ideas is one off versus on schedule Aaron: substantially agree, but notifications can be regular too ... notifications are about a change in relationship between parties Olga: reports have a unit of count, notifications dont Mark: i like that distinction ... ad-hoc can be a reporting frequency ... the unit of count says if something is a report Ben: do we need two terms? Aaron: yes both terms ... keep it close to language thats used Ilya: agree Mark: now the duty to invoice ... the debtor has the duty to invoice ... the user of data isnt required to pay until invoiced ... but payment can be made without invoice too Olga: is it a voluntary or must duty? Mark: if invoice not generated the originator is not in breach Ben: are there contrcats where the provider does have to invoice before payment? Olga: not sure, not seen it described Ben: a question to stephen on this, is invoicing informal activity Stephen: i think it varies ... should go hand in hand Ben: i think we can model it both ways, invoice obligation bot tied to payment Aaron: just because no invoice doesn't change the requirement to pay Ben: this context is if you don't pay your permission is invalid Mark: can we use the ODRL permission vs the duty Ben: not really ... a duty cant be optional ... can be a free-floating obligation ... that doesnt impact a permission Mark: attribute now, obligation to attribute <benws> https://w3c.github.io/market-data-odrl-profile/Vote <Ilya> +1 <benws> +1 RESOLUTION: accepted terms in vote doc except report and notify Ben: no time to discuss temporal issues today ... please could people read document and provide input and examples Any Other Business Ben: none today Summary of Action Items Summary of Resolutions 1. Last meeting minutes accepted<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#resolution01> 2. accepted terms in vote doc except report and notify<https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html#resolution02> [End of minutes]
Received on Wednesday, 22 July 2020 16:14:40 UTC