<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

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)


WARNING: Replacing previous Present list. (Old list: Ben, Phil, Mark_B, Natasa, Josh_C, Ilya, Jo, Paul_K, Stephen_D)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Ben, Phil, Mark, Natasa, Josh, C, Ilya, Paul, K, Stephen, D

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
No ScribeNick specified.  Guessing ScribeNick: Phil_R
Found Scribe: Phil

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)