Data Model WG Calls are suspended while Architecture works on progress
Truman:
As applications emerge, Architecture will evolve
Architecture that is good enough for primary use case
From TSC call on 5/5: can't address all use cases up front, address 1 & 2
JeffB
Right to focus on plan to address infrastructure
what are the other types of patterns they MAY exists that may effect it in some fashion
Truman - first one being
JeffB - stat reporting
Truman - suggest we create WG to target that, another for North Dakota DMV use case
are there openIDL facilities to do that, helpful to illustrate how we are doing it, stateless type of use case (not stat reporting)
Stateless: every day, does this vehicle have insurance - yes or maybe or no
Only historical if you save it
David wants to get to maintain state of every policy as good as you can
Ken
David agreed that history is part of the deal
Truman - for stat reporting it must be
Jeff
North Dakota shouldn't be a heavy lift, important to have knowledger, just doing something
Truman
Suggest, Mississippi - addresses, kept private, to solve problems
USAA - if you can do MISS, you can do stat reporting which is automatic
Jeff
purpose for setting out those use cases
Truman - what we got to, DMWG isn't considering anything but stat reporting
ND DMV project is very simple
Jeff - whats done could be used for a variety of purposes
Truman - whats the extraction pattern of the DMWG that would provide the report
what are the data fields the report extracts to
did the data model - didn't get to the report
data in data store, so this query can run into each. node
what you deploy with one policy vs large carriers
diff arch, diff choices
any datastore you want
spreadsheet, policy admin system, whatever an org trusts
then need to attest to the level of qual to the network
What arch are we going to solve for (examples)
Ken - similar opinion for this group
evolved to the point where we need travelers and hartford want to do POC solves reporting, know it doesn't solve all
spin off - if we retitle this to be stat reporting arch wg, we know focus, but shouldn't be the only focus
need to have a focus that says, this is the focus of this group, can get feeds from other groups
HHT want to be distracted by those other things
hosted node, adapter running
Truman
whats that arch going to do?
Ken
regulators (Eric, George) - we assert process not the actual data
think about the proccess
Truman - challenge our own internal processes
Regulators want to go faster, but reqs are we reconcile data, which we dont get until just now
we dont have the checksum to deliver faster unless they say "we will take it faster and lower quality bar"
JeffB
this WG should be oversight Arch WG and have others for use cases
take into account other considerations
if you say this group is only stat reporting and other groups
Truman - we need to have room for other use cases
JeffB - to use the example, we are all building with gravity but need plumbing and sewerss, etc.
Truman - data privacy and information quality, provenance of the answer being provided
JeffB - dont we have to deal with the infra and technology
Truman - done
Ken - no we don't, we have. a picture, no hosted node - no adapter - now lets make them real
Truman - not just define data model in harmonized data store but also how it operates
walk it all the way through - one report for 52 states, history is there, looking at queries run against stat data
Ken - ND can be done with existing arch with some security mitigations
different thread, discussion not really architecture based
Truman - transaction patterns lightweight,
Satish - stat reporting and other use cases, doesn't know ND use case
expand on use case for this is how it will fit
what is the real scope? Stat reporting, ND, Mississippi?
is this beyond stat reporting
Truman - wanted to focus on stat reporting in the last meeting, deal with other projects as they come, not yet mature, and open to other members
Joan - questions - openIDL platform arch group is looking at, has a role to accept request for info, extraction and maybe transformation of that data, sent back to openIDL platform to receivwer
in the case of stat reporitn, platform needs to recieve the req, process on carrier's side, get answers back
ND - similar, req for info, processed, info sent back out
use case is the same, describe use case in terms of core functionality, see if applications use of openIDL
doesn't seem to be wildly different between the 3 use cases
Ken - didn't mention non funct requirements
when we put the whole node (as previously recommended) found out it was a no-go
arch that allows data to be private, functionally we can do the ND POC without refactoring, but do not have data privacy at the level we want
Joan - lets not get into details of ind use cases
if you want to separate where data stored and processed, if we take on that issue, and resolve it, and then we do desktop exercise of anythign not be done for MS or ND or stat reporting
still doesn't think there is a hinderance
hoping group can focus on separating the data processing from the openIDL node - focus and test arch against the 3 applications we have in front of us
Ken - think what we heard from RR WG and TSC - lets not put datamodel in front of that, do it with Stat Reporting to get agreement
JoanZ - can do ND today without this, if you rearch you still can do ND or Miss Crisis track
Ken - diff is the data model, can't support with new arcjhitectures yet
we want to do the ND with the new data model, doesn't see reason why we can't put new data model in, said to use current stat plans as data model
very easy to support mult data models, nuance but it is there
technically as soon as we have stat reporitng working with old stat plan, new use cases are trivial
Truman - could do stat reporting, accelerate timeframe, (2021 homeowners on fri), wold make them happy to make it faster
simply stat plan and same reports
JoanZ - for this Arch WG - if we focused on splitting the platform in 2 - data repository and processing of that data, secure and private in carriers data center and other part of open IDL is participaitng in network receiving requests and sending responses
what are the steps that need to be done to split the platform in two to meet the needs
unaware of any application that would be stopped, could still move forward with three applications in front of us
Satish
trying to document what steps
Stage data (carrier), request data, process the data, extract data, combine data, publish data
structure the thoughts and arch as well
ken - need to meet non-functional requirements of timeliness, quality
JoanZ - multi-funct platform, network, with nodes, deliver functions, dont tailor to any one use case, provide platform that meets needs
Truman - lay out each use case - what data needed, extraction, publish: by staging 1 kind of data set can work with mult use cases
one address applies to mult use cases
this one needs monthly, this one annual, this one quarterly
JeffB
data pipeline is right - needs to have "communicate or transmit" added -
Truman - need to connect openIDL pipelines, now from the data owner/node delivers to analytics node, current use case analytics node is run by AAIS
we run compilation manually - regulators, thats not how they get stat reporting data, they dont have an analytics node yet, can combine data in tableau report, give Regs access to that
JeffB - extraction - extract data from HDS based on request, needs to be collected and x before combined
Truman - request, extraction pattern goes to node and they consent, they say "yes" and then extraction occurs, sent to analytics node
JeffB - receipt of request locally
Truman - transmission baked in
after extraction data piped from data owner node to analytics node
current model is manual process
JeffB - messaging arch of sorts, diff types of data, particular report, streams of data, hash written onto chain, one of the things to address: what is the architecture/schema for sending data
Ken - that's private data collection
Truman - payload of what these things are,
JeffB - diff types, our responsibility of how to distinguish that data
Truman - each use case does, yes
perform function of the functions
put whatever payload in gossip protocol, gigs of data, stream vs batch
Jeff - suggesting clarity that aspect should be documented
Truman - pushed that desicrip to each use case (priv, access, granularity, freshness, etc.) what does that use case support? what does the arch needs to support (or enhance) to support new use case
is it good enough for what I need
purpose defines arch
ken - if we can say time series and format are orthog to primary arch, define use case and constraints - this group focuses on the infrastructural arch (HDS, extract patterns etc are use case specific) but movement of data
Truman - whatever is neccessary for purpose each node is participating in
ways we can make this very simple
solve problems
regardless of use case - biggest issue - is time-series
what openIDL does is provide assurances of data owner, staged according to use the data will be inc into
whatever network gets passed a token for the data = "the data is this good"
some companies giving data quarterly or monthly - if we simply had check that says all companies met the rules
Ken - verification can change, reporting and combo steps can change
Satish
data pipeline - staged-etc. - that would be on the x-axis
y axis - do we need time series in this stage, do we need in combine? (example)
data privacy?
grid
Truman - transparency - first is control
if data owner agrees to do that, select-all, publish - may or may not give them privacy
privacy from anonymity of each pub of data
analytics node owned by AIS (right now) - could know who reported what/when
Satish
next meeting
data pipeline steps are agreed upon
list the qualitities which could be a use case for each step in the pipeline
