<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
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
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)
jo: hearing none, meeting closed
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) Succeeded: s/annoucemnet/announcement/ Succeeded: s/???/Olga/ Succeeded: s/udit/audit/ Succeeded: s/Ale/Alex/ Succeeded: s/michell/michelle/ Succeeded: s/th/the/ Succeeded: s/meaninfs/meanings/ Succeeded: s/]ben/ben/ Succeeded: s/Bena nd MarkB to go away and consider the points made/Ben and MarkB to consider the points made and report back with a porposal/ Succeeded: s/everyone/everyone to review material on ISSUE-14 in preparation for a determination at next meeting/ Succeeded: s/linked through to the issue thread/Jo: linked through to the issue thread/ Succeeded: s/Jo: linked through to the issue thread/MarkB: linked through to the issue thread/ Succeeded: s/intot he model or nto/into the model or not/ Succeeded: s/toher/other/ Succeeded: s/hisotry/history/ Succeeded: s/like top work/like to work/ Succeeded: s/ewveryone/everyone/ Succeeded: s/shceduled/scheduled/ Succeeded: s/notification. does/notification/ Succeeded: s/hte/the/ Succeeded: s/Mark_B/markb/G Succeeded: s/mark_B/markb/ Present: mark_bird Ben jo Alex_Cravero Ilya Liz Laura Caspar joshC atiq aaron phil michelle Regrets: Natasa Stephen renato No ScribeNick specified. Guessing ScribeNick: jo_ Found Scribe: Jo Agenda: https://w3c.github.io/market-data-odrl-profile/agendas/md-odrl-profile-agenda-2020-08-05.html 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: ben everyone markb 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.)[End of scribe.perl diagnostic output]