Minutes of the W3C Rights Automation Community Group 2020-08-05

Please find the minutes of today’s meeting at https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html and pasted below.

Summary of Action Items

ACTION: Ben and MarkB to consider the points made and report back with a proposal
ACTION: everyone to review material on ISSUE-14 in preparation for a determination at next meeting


Summary of Resolutions

  1.  Accept minutes of last meeting<https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html#resolution01>

Many thanks
Jo


Rights Automation Community Group Teleconference
05 Aug 2020

Agenda<https://w3c.github.io/market-data-odrl-profile/agendas/md-odrl-profile-agenda-2020-08-05.html>

Attendees
Present
mark_bird, Ben, jo, Alex_Cravero, Ilya, Liz, Laura, Caspar, joshC, atiq, aaron, phil, michelle
Regrets
Natasa, Stephen, renato
Chair
jo
Scribe
Jo
Contents

  *   Topics<https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html#agenda>
     *   Admin<https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html#item01>
     *   Discussion of temporal aspects - ISSUE-14<https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html#item02>
     *   Uddated definitions of notify and report<https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html#item03>
     *   AOB<https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html#item04>
  *   Summary of Action Items<https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html#ActionSummary>
  *   Summary of Resolutions<https://www.w3.org/2020/08/05-md-odrl-profile-minutes.html#ResolutionSummary>

________________________________
Admin

<scribe> scribe: Jo

Minues of last meeting: https://www.w3.org/2020/07/22-md-odrl-profile-minutes.html


jo: any comments?

RESOLUTION: Accept minutes of last meeting

Discussion of temporal aspects - ISSUE-14

Ben: does a model today or also past, present and future is a decision that needs to be made
... discussion intended to identify costs and benefits
... then invite aaron to comment on how often folks have changed their polciies and not how frequent they are
... there are two modelling options we could take.

markb: link to some notes on the topic

https://w3c.github.io/market-data-odrl-profile/discussions/2020-08-05/topics


scribe: MarkB: linked through to the issue thread
... define why we need to consider time based aspects
... then look at use cases
... time based concepts are required for audits
... need to know what was the state at the time we are auditing
... also things change over time, prices in particular
... finally forecasting ... what will happen in the future
... are these three use cases sufficient
... anyone want to champion the contrarian point of view i.e. we can work with just a present state definition

jo: need for temporal aspect is sperate to the question of how to model that temporal requirement

markb: yes, good point, we'll cover that

Ben: to add to that, should people just use other tools to model the temporal aspect
... do we need the description of the history to be interoperable? If so then we need the model to be temporal
... but if rarely enough then as long as people can retrieve point in time?

Ilya: in addition need to know when something starts and when something ends

MarkB: so far we have discussed the effective period, when do changes get applied
... rather you are referring to when the change get made?

Ilya: yes, I'd like to propose that for consideration
... if that's an issue then we need to be careful when building the model

Ben: yes we need to make that distinction
... building a model that supports actual time is much simpler than a model that supports bi-temporality

Atiq: to take a step back ... we are talking about policy/contract management across time
... we are discussing whether to build this into the model or not?

Ben: yes, it is. It's a question as to whether we should.
... we could do in a light-touch, by adding from: and to: to rights and duties
... one step further would be to note when the definition of something changes
... so things like duties areally are temporal objects and we consider versioning them, allowing ids to be stable over time
... if this is valuable and important we need to put that in the model

Atiq: yes we do need to maintain temporal aspects and there are pros and cons to the two apporaches

Ben: aaron went and had a look at how often changes are made to policies
... it surprised me to find out how often things do change

https://raw.githubusercontent.com/w3c/market-data-odrl-profile/gh-pages/resources/DBNYSEStats.pdf


Aaron: went through our system and looked at Deutsche Borse and NYSE
... how often we made announcements, things are significant, any one announcement is 100s or 1000s of prices changes
... start is how frequently the events happen with some indication of the nature of the change
... note that 2018 was MIFID 2 which could be considered exceptional, but even so
... (discussion of the data in the file, and pointing out the significance)
... gives and idea of how many changes there are that need to be kept up to date with this model

Ben: not sure what conclusion to draw, other than it's a significant decision to make

alex: there are a lot of changes through contract lifecycle ...
... version control is one way but there are technical complexities

Laura: I think if we have the effective dates in, that would be important. we had a situation in an audit
... where we had to go back and ask when did this exchange change its non display definition
... critical topic, must have at least effective dates as a minimum

ilya: need effective dates, but also all the transitions

Olga: not just the change but be able to trace the change back

aaron: what are we trying to do with that history?
... struggling to see a world where an audit is digital
... see that as being much more a human mediated process

laura: yes, I agree
... need effective dates, automation limited to current policy,

mark: are we trying most importantly to make a spec that control entitlements
... is that mutually exclusive to the audit objective
... don't want to miss the point that the thing for humans is important

Alex: the questions is how much this refers to dispute resolution

Ilya: the force of law rmains with the docs not the digital representations
... digital representations can tell us how things change
... cant we rely on kind of source code control to inform us
... you can see the transitions

michelle: similar is the pricing
... you'd keep that in your inventory system

ben: from refinitiv's perspective, being able to automate notificiations is a very interesting feature
... we'd like to work with our suppliers and customers ... that would be a big win
... summarising: effective from and to could be a valuable addition to the model
... but need more comments on "do we need stable identifiers' then one more step is needed

MarkB: stable identifier to clarify ...

Ben: Important for assets more than duties, if the identifier for the asset changes
... if we want to make sure they don't change then take a step further
... there is a model in the doc

Ilya: want to challenge the group to come up with a truly stable id

Jo: action on everyone to read this and comment before next meeting so a determination can be made

<scribe> ACTION: everyone to review material on ISSUE-14 in preparation for a determination at next meeting

Uddated definitions of notify and report

Mark: noting the changes that Ben made to Notify and Report
... there are other possible meanings
... scheduled vs unscheduled
... structured vs unstructured
... Ilya had an objection to that, notification could still be something that we had a definition to, as opposed a report
... Olga suggested a unit of count as the differentiator
... first question, any other thoughts about what makes a report different to a notification
... I think timeliness is not the right answer - scheduled vs unscheduled
... up to the reporter to decide
... identical things treated differently only on the basis that one is ad hoc the other is not

Aaron: unit of count is the key

jo: if no one can tell the difference why aren't they the same thing

aaron: historically this was the language

olga: report has structure, notification doesn't
... reporting has parameters, notification not

mark: in general agree with that, how do we put that in a definition

ben: report is more structured and is likely to be parameterised, does that capture it?

olga: parameter means you insert a value - count time etc.

ben: structured response on the basis of a specification

markb: leaning towards structured vs unstructured
... ilya are you happy with that as the one who pushed back before?

ilya: I liked the idea of removing the difference as Jo said
... the content doesn't necessaily need a distinction

ben: I'm sympathetic - we are struggling to make a distinction - so why don't we simplify
... my hesitation comes from abandoning terms of the art, people use these terms
... if we remove one or another that will be confusing

jo: not as confusing as if you can't tell people what the difference is

aaron: thing this is about historical vs present or future

olga: notificiation is about events

ben: mark and I to go away and come back with a report

<scribe> ACTION: Ben and MarkB to consider the points made and report back with a porposal

(noting a point also from Aaron about how the report/notification is generated)

AOB

jo: hearing none, 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.